panates / opra / 39385435168

86%

main: 86%

push

github

fix(nestjs-http): Let several OpraHttpModules share one application

Two modules in one Nest application answered each other's error paths
with 500 in place of the status the error carried.

Each module applies its middleware to every route — a module does not
know which paths are its own — so both ran on every request and the
single `req.opraContext` slot held whichever one happened to run last.
A handler then configured a context its own adapter had not built, with
the other API's document behind it.

The status itself was lost one step further on. `OpraMiddleware`, the
core module's constructor and `OpraExceptionFilter` all injected the
adapter by class, which is only the *default* value of
`ModuleOptions.token`: a module configured with a token of its own
registers no provider under the class at all. The filter's
`moduleRef.get(OpraHttpNestjsAdapter)` threw inside `catch()`, so the
mapped status was never written. The same mistake made
`onModuleDestroy` close one adapter once per module and never close the
others. `opraHttpNestjsAdapterToken` had been declared and registered
for exactly this and was never injected anywhere.

Each module now registers that symbol, `OPRA_HTTP_ADAPTER`, as
`useExisting: <its own token>` in its `providers` alone — never in
`exports`, so it cannot leak through `@Global()` — and resolves its
adapter through it. Contexts are keyed by adapter, one slot per module,
and `req.opraContext` keeps meaning "the active context": the last
middleware's until a handler replaces it with its own. Generated
controller classes carry Reflect metadata naming the adapter that built
them, which is what lets the filter answer an error raised before any
handler ran — a global guard rejecting a request, where the request
carries one context per module and nothing else says which route
matched.

Nothing changes for a single module, and distinct `basePath`s are not
required: the two APIs are told apart by their adapters, not by their
paths.

Co-... (continued)

4818 of 6169 branches covered (78.1%)

Branch coverage included in aggregate %.

234 of 245 new or added lines in 7 files covered. (95.51%)

41085 of 47225 relevant lines covered (87.0%)

313.77 hits per line