-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(common) #62: Message routing headers #70
feat(common) #62: Message routing headers #70
Conversation
lilgallon
commented
Jan 17, 2024
•
edited
Loading
edited
- closes Provide request context to services #62
- closes Paginated response header override all other headers #69
// This is an example, you will probably need something more specific | ||
// if you want to handle message routing headers | ||
val requestMessageRoutingHeaders = currentRequestMessageRoutingHeadersOrNull() | ||
val responseMessageRoutingHeaders = currentResponseMessageRoutingHeaders() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may I suggest adding a method to the RequestMessageRoutingHeaders that inverts itself? Something like
invert(): ResponseMessageRoutingHeaders
alternative names could be toResponseRoutingHeaders
, toResponse
or alternatively have a secondary constructor on the ResponseMessageRoutingHeaders
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I like the idea.
About the name, at firs glance t I liked invert
, but it makes me feel it will return an inverted request routing headers. Therefore I would prefer toResponse
despite it doesn't convey the inversion.
Alternatively it could be a companion object method on the response, so that you would use it like this: ResponseMessageRoutingHeaders.invertFromRequest(requestMessageRoutingHeaders)
That's longer but I think it's more explicit.
@@ -63,7 +60,9 @@ class Http4kTransportServer( | |||
} | |||
.also { httpRequest -> filters.forEach { filter -> filter(httpRequest) } } | |||
.let { httpRequest -> | |||
httpRequest to runBlocking { | |||
httpRequest to runBlocking( | |||
httpRequest.messageRoutingHeaders() + ResponseMessageRoutingHeaders() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we "invert" by default. unless you implement a HUB, a server would always need to mirror the clients routing headers. Similar to how we already handle request/response message ID headers automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely, good suggestion!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good for me
…sponses when provided
…ing header & updated integration tests accordingly
Request & Correlation id values are not deterministic in this test. They are already tested in credentials integration tests
7169cf5
to
0911532
Compare
|