A running run names its step - #130
Merged
Merged
Conversation
A run whose calls fold into its row said "Working…" — the phase, which exists for what the timeline can't show, standing in for a step the timeline knew by name. It only bites with one call in flight, the moment the step matters most; a second call splits the rows and the name comes back. agent_running mapped to a label that duplicated the timeline and read worse, so it maps to nothing now and the row reads its running call. The sub-line moves to statusLine, where the extension keeps its words.
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
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.
The bug
A running build showed "Working…" where it should have said "Generate plan". The INFO panel on the same screen said "Generate plan" — so the name was right there, one component away.
Two different things render, and only one names the step:
statusLine(status)→kindLabel(status.agent)→ "Generate plan"activity.label→ the phase → "Working…"It only bites when a run has one call in flight, because the row folds the call into itself:
Folded, the call's own row is gone, so the name goes with it and the generic phase fills the gap. A second call splits the rows and the names come back — which is why this looks intermittent, and why it hides the step at exactly the moment there's only one thing happening.
The cause
SubjectActivitysays what it is for:It exists for the gap before an agent call exists. But the phase map broke its own contract:
agent_runningreported a label for the one case the timeline covers, and reported it worse. Its only real effect was handing the frontend a plausible generic string to render by mistake.The change
Backend —
agent_runningmaps to nothing.SubjectActivityis infra-only again, so there is no generic label available to render wrongly. The phase itself still fires; it's what clearsprovisioning_vm.Frontend — a running run's sub-line reads its running call's label when the calls are folded in, and the infra phase otherwise. Fixing the good option to win would have left the bad one reachable; removing it makes the correct thing the only thing.
The sub-line moves out of a five-branch ternary into
runSubLineinstatusLine.ts, which already declares itself the home of the extension's words.STATE_LABELwent with it — it had no other caller — soWorkItemPageloses a constant.Verification
tsc,eslint,ruffclean. Six new cases instatusLine.test.ts(14 pass): the folded step names itself; split calls leave the name to their own rows; the infra phase still shows before an agent starts; and parked/failed/scheduled are unchanged. The test factories build realRunSummary/AgentCallSummaryvalues with noascasts, so they typecheck against the actual shapes.Five backend files are unformatted on
mainand untouched here; left alone rather than padding the diff.