As reported in this Stackoverflow question, the CoroutineContext defined in the parent router is lost in nested routers, which is a surprising behavior. For example with this router, a request on / will have the context set as expected, but not a request on /nested/.
coRouter {
context { CoroutineName("Custom context") }
GET("/") {
ok().bodyValueAndAwait(currentCoroutineContext().toString())
}
"/nested".nest {
GET("/") {
ok().bodyValueAndAwait(currentCoroutineContext().toString())
}
}
}
This issue is about inheriting the CoroutineContext in such use case to provide a more predictable behavior, while still allowing an override in nested routers.
As reported in this Stackoverflow question, the
CoroutineContextdefined in the parent router is lost in nested routers, which is a surprising behavior. For example with this router, a request on/will have the context set as expected, but not a request on/nested/.coRouter { context { CoroutineName("Custom context") } GET("/") { ok().bodyValueAndAwait(currentCoroutineContext().toString()) } "/nested".nest { GET("/") { ok().bodyValueAndAwait(currentCoroutineContext().toString()) } } }This issue is about inheriting the
CoroutineContextin such use case to provide a more predictable behavior, while still allowing an override in nested routers.