Report actual senders and external input in SuperStepStartInfo - #1005
Conversation
stepTracer.Advance derived SuperStepStartInfo from StepContext.Keys(), but StepContext is keyed by the message TARGET (MessagesFor(target)). So SendingExecutors was populated with the executors that RECEIVE the step's messages rather than the ones that sent them (contradicting its doc), and HasExternalMessages was dead code: the map key is never the empty string, so the external branch never fired. The sender/external signal lives on each envelope: SourceID names the sender and an empty SourceID (IsExternal) marks external input. Iterate the queued envelopes and collect distinct non-empty SourceIDs as SendingExecutors, and set HasExternalMessages when any envelope is external.
There was a problem hiding this comment.
🟢 Approval recommended
The change aligns SuperStepStartInfo with its documented semantics and adds a targeted regression test covering the previously incorrect behavior.
Pull request overview
Fixes SuperStepStartInfo reporting in the in-proc workflow tracer by deriving sender/external-input metadata from queued MessageEnvelopes (source-of-truth), rather than from StepContext’s target-keyed map.
Changes:
- Update
stepTracer.Advanceto computeSendingExecutorsfromenvelope.SourceIDandHasExternalMessagesfromenvelope.IsExternal(). - Preserve determinism/uniqueness of
SendingExecutorsvia sort + compact. - Add a regression test validating correct sender vs receiver reporting and external-input detection.
File summaries
| File | Description |
|---|---|
| workflow/inproc/tracer.go | Build SuperStepStartInfo from message envelopes so senders and external inputs are reported correctly. |
| workflow/inproc/events_test.go | Adds regression test ensuring senders/external inputs are correctly reflected in SuperStepStartInfo. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Scope: user-visible behavior (internal Changed Go contract: No exported types/fields were added, removed, or renamed. Upstream evidence reviewed:
Result: aligned. This is a Go-internal correctness fix that brings the computed values in line with the documented Warning Firewall blocked 1 domainThe following domain was blocked by the firewall during workflow execution:
To allow these domains, add them to the network:
allowed:
- defaults
- "github.com"See Network Configuration for more information.
|
Problem
stepTracer.Advance(workflow/inproc/tracer.go) buildsSuperStepStartInfofromStepContext.Keys(). ButStepContextis keyed by the message target (MessagesFor(target)— "messages queued for the given target executor"). So:SendingExecutorsreports receivers, not senders. Its doc says "the unique identifiers of Executor instances that sent messages during the previous SuperStep", but it was populated with the executors that will receive/run the step.HasExternalMessagesis dead code. Theidentity == ""branch never fires because the map key is the target ID (never empty). The external signal lives on the envelope (MessageEnvelope.SourceID/IsExternal()), whichAdvancenever inspected — so it was alwaysfalse, even for the initial external input.Fix
Iterate the queued envelopes (
step.MessagesFor(target).All()) and derive the info from each envelope: collect distinct non-emptySourceIDs asSendingExecutors, and setHasExternalMessageswhen any envelopeIsExternal()(emptySourceID).Test
TestSuperStepStartInfo_ReportsSendersAndExternalMessagesrunsstart → sinkwith an external input and asserts: the first superstep hasHasExternalMessages == true; the pure receiversinkis never listed as a sender; and the actual sendermessage-handlerappears inSendingExecutors. Fails before the fix (HasExternalMessages=false,SendingExecutors=[sink]), passes after. Full./workflow/...suite green under-race -shuffle.