The current RegisterTrigger API passes only m.Data (raw bytes) to the user-supplied callback, discarding the NATS message headers. This makes it impossible to access per-message metadata; auth context, tracing IDs, tenant identifiers, etc. - inside a trigger function.
Proposed Change
Add a companion method RegisterTriggerWithHeaders on Runner that passes the full *nats.Msg to the callback instead of just the payload bytes
- The reply-message path already attaches workload_id and namespace headers, so the plumbing for header-aware messaging is already present.
- RegisterTrigger could be reimplemented as a thin wrapper over RegisterTriggerWithHeaders to avoid duplicating the subscribe/publish/event-emit body.
Happy to do that in the PR if preferred.
The current
RegisterTriggerAPI passes onlym.Data(raw bytes) to the user-supplied callback, discarding the NATS message headers. This makes it impossible to access per-message metadata; auth context, tracing IDs, tenant identifiers, etc. - inside a trigger function.Proposed Change
Add a companion method
RegisterTriggerWithHeadersonRunnerthat passes the full*nats.Msgto the callback instead of just the payload bytesHappy to do that in the PR if preferred.