{{ message }}
fix(web): keep for-each dive-in clickable for running items#273
Merged
jrob5756 merged 2 commits intoJul 1, 2026
Merged
Conversation
vigneshwarKV
pushed a commit
to vigneshwarKV/conductor
that referenced
this pull request
Jul 1, 2026
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
The per-item "Dive into subworkflow" control in the for-each group detail panel was a `<span role="button">` nested inside the row's expand/collapse `<button>`. That outer button is `disabled` whenever the item has no expandable details (`hasDetails` false) — the case for a running workflow-type iteration that has not yet produced a prompt/output/activity/ error. A disabled `<button>` suppresses click events across its entire subtree, so the nested dive-in never fired while the item was RUNNING. Once the item FAILED (carrying an `error_type`) or COMPLETED, `hasDetails` became true, the button was enabled, and dive-in worked — matching the reported "only navigates when FAILED" behavior. Restructure the header row so the expand/collapse toggle and the dive-in control are siblings inside a plain flex `<div>` rather than nesting an interactive element inside a (sometimes disabled) button. The dive-in is now a real `<button>`, so it stays clickable regardless of the toggle's disabled state and no longer relies on `stopPropagation`/manual keydown handling. This also removes the invalid nested-interactive-element markup. Rebuilds the bundled dashboard (`make build-frontend`); the static/ changes are the regenerated Vite bundle (content-hashed filenames) with index.html pointing at the new hashes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
a1ee1cf to
6e03d33
Compare
jrob5756
approved these changes
Jul 1, 2026
jrob5756
left a comment
Collaborator
There was a problem hiding this comment.
Approving. Validated the root cause and fix end-to-end, plus a multi-agent review (code quality, tests, comments, dead code, simplification): the dive-in is correctly un-nested from the disabled toggle so it stays clickable for running for-each items. Improves a11y (native button), removes invalid nested-interactive markup and the manual keydown/stopPropagation shim, passes tsc -b, and the rebuilt bundle is byte-identical. Only optional nits remain (aria-label, type="button" on the toggle, a frontend test-harness follow-up).
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.

Problem
In the web dashboard's for-each group detail panel, each row under ITEMS has a stacked-layers "Dive into subworkflow" control. Clicking it navigates into the iteration's nested workflow — but only when the item is
COMPLETEDorFAILED. While an item isRUNNING, clicking the icon does nothing.Root cause
The dive-in control was a
<span role="button">nested inside the row's expand/collapse<button>:The outer toggle is
disabled={!hasDetails}, wherehasDetails = prompt || output != null || activity?.length || error_type. A running workflow-type iteration hasn't produced any of those yet (its prompt/output/activity live on the childSubworkflowContext, not on the for-each item), sohasDetailsisfalseand the outer button is disabled.A disabled
<button>suppresses click events across its entire subtree, so the nested dive-in span never received the click. Once the item failed (thefor_each_item_failedevent carries anerror_type) or completed,hasDetailsflipped totrue, the button was enabled, and dive-in worked — exactly matching the "only navigates when FAILED" symptom.The store's
navigateIntoSubworkflowand theSubworkflowContextfor the running iteration were both fine (the context exists as soon assubworkflow_startedfires, so the icon correctly renders for running items) — the click simply never reached the handler.Fix
Restructure the header row so the expand/collapse toggle and the dive-in control are siblings inside a plain flex
<div>, instead of nesting an interactive element inside a (sometimes disabled) button. The dive-in is now a real<button>, so it:disabledstate,role/tabIndex/onKeyDown/stopPropagationshim), andOnly
GroupDetail.tsxchanged behaviorally; thestatic/bundle is the rebuilt frontend (make build-frontend).Verification
Reproduced against a real for-each fan-out (two concurrent workflow-type iterations): before the change, the dive-in icon was inert on the
RUNNINGrow and worked on theFAILEDrow; after the change it navigates into the nested workflow in both states.tsc -b(viamake build-frontend) passes.