Uh oh!
There was an error while loading. Please reload this page.
fix(web): keep for-each dive-in clickable for running items - #273
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Vigneshwar (vigneshwarKV)
commented
Jul 1, 2026
@microsoft-github-policy-service agree company="Keyvalue" |
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
6e03d33CompareCodecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## main #273 +/- ##
=======================================
Coverage ? 89.03% =======================================
Files ? 69 Lines ? 12281 Branches ? 0 =======================================
Hits ? 10934 Misses ? 1347 Partials ? 0 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Jason Robert (jrob5756)
left a comment
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).
Uh oh!
There was an error while loading. Please reload this page.
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.