Stop Middleware shortcutting when filter is used #81
Conversation
|
Cool! I will take a look tonight. |
twitchax
left a comment
twitchax
left a comment
There was a problem hiding this comment.
Overall, LGTM, but I might add an enum to make the Intercept and Filter options easier to understand.
| var httpProxy = new HttpProxy((c, a) => new ValueTask<string>(httpEndpoint), httpProxyOptions); | ||
| var wsProxy = new WsProxy((c, a) => new ValueTask<string>(wsEndpoint), wsProxyOptions); | ||
| var proxy = new Builders.Proxy(null, httpProxy, wsProxy); | ||
| return controller.HttpContext.ExecuteProxyOperationAsync(proxy); |
There was a problem hiding this comment.
Might want to show the throwaway result.
There was a problem hiding this comment.
Yeah I wasn't sure on this one, didn't want to change the API but the user of this API can still choose to ignore the result and it should be their choice, an Enum would be the best output for them
|
|
||
| if (options?.Filter != null && !options.Filter(context)) | ||
| { | ||
| return false; |
There was a problem hiding this comment.
We can probably keep this, but I feel like, now that there are two filter options, this may call for an enum to be more clear than a bool. I might just clean it up after, and then bump a major version.
There was a problem hiding this comment.
You're right, I wanted to add it with boolean because it would be the simplest implementation. But the code is much more confusing because of that, an Enum absolutely solves this. I'll try to make a change later today.
2 participants
Implementation for #80
This change passes a bool up the stack to the middleware layer to say if the pipeline should be short-circuited
I think this first go isn't probably the right approach but is worth having a discussion over to see what is needed.