Repository navigation
typescript: join a message key's sender to its handler (remote_edge) - #1822
Merged
swapnilpaliwal-sd merged 2 commits intoSep 30, 2026
Merged
swapnilpaliwal-sd merged 2 commits into
swapnilpaliwal-sd merged 2 commits into
Conversation
A producer that emits on a key (a Nest microservices client's emit/send, a
kafkajs producer's send({ topic })) was not joined to the handler registered
on the same key (@EventPattern / @MessagePattern, a kafkajs consumer's
subscribe), so path stopped at the send and impact of a handler named no
sender.
destinations.dl gains a messaging section. Both ends are recognised by the
receiver's DECLARED type and the package it is imported from (knobs.dl,
ts_msg_client_type), never by the method name, so emit on a Node event
emitter is not a send. The key is read the way a route is: a literal, a
const, a const-object member (now also through `as const`), local or
imported. One wrapper hop is bound: a private send(pattern, x) called with
the key joins from its caller. A decorator's Transport argument names the
broker; an end that names none joins any. One-sided keys are reported as
remote_unserved / remote_unsent, an unreadable key as remote_undetermined.
remote_unsent is judged by destination, so a handler reached by a send that
names no broker is not also reported unsent.
Checked: new CLI case cross-process-message (emit on an imported const-object
member, send on a const, a key through a wrapper, kafkajs send/subscribe,
controls: an EventEmitter emit and a handler nobody sends to) fails 5/7
before and passes 7/7; typescript case suite 212/212, engine suite 99/0. On a
monorepo with three services: probes 44 -> 47 of 74, no regression, call
edges unchanged, 5 amqp + 2 kafka remote edges added.
Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.com>
swapnilpaliwal-sd
requested review from
JaredHLZhang,
Whua689 and
suyashpaliwal26
as code owners
September 30, 2026 10:02
swapnilpaliwal-sd
deleted the
apps/typescript/ts-message-broker-join
branch
September 30, 2026 10:53
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A send on a message key (Nest microservices client
emit/send, kafkajsproducer.send({ topic })) was never joined to the handler on the same key (@EventPattern/@MessagePattern, kafkajsconsumer.subscribe).pathstopped at the send;impactof a handler named no sender.destinations.dl: new messaging section emittingremote_edge(transport from the decorator'sTransport.X, ormessagewhen neither end names one), plusremote_unserved/remote_unsent/remote_undetermined.knobs.dl,ts_msg_client_type), never by method name. SoEventEmitter.emitis not a send.as const), local or imported across packages.place() { this.send(CMD.place, x) }oversend(pattern, x) { this.proxy.send(pattern, x) }joins fromplace.remote_unsentis judged by destination, so a handler reached by a send that names no broker is not also reported unsent.Checked: new case
cross-process-messagefails 5/7 before the fix and passes 7/7 after (controls: EventEmitter emit, a handler nobody sends to). TS case suite 212/212, engine suite 99/0. On a 3-service monorepo, probes went from 44 to 47 of 74 with no regression. Call edges are unchanged (10045) and the HTTP remote rows are unchanged; 5 amqp + 2 kafka edges were added.