fix(run-insights): TUI wizard state, inline name validation, job history#1602
fix(run-insights): TUI wizard state, inline name validation, job history#1602notgitika wants to merge 1 commit into
Conversation
…inline, surface job in history Multiple fixes to the `agentcore run insights` interactive wizard: - **Single-agent flow** (#4): when the project has exactly one agent, the wizard skipped the agent step but never set `config.agent`, so the Confirm screen showed a blank "Agent:" line. Pre-populate the sole agent in the default config so it's threaded through to confirm and the API call. - **Inline name validation** (aws#6): the Name step accepted invalid values (spaces, hyphens, leading digits) and only failed at submit time when the API returned a 400. Validate inline against the service-side `BatchEvaluationName` pattern (`^[a-zA-Z][a-zA-Z0-9_]{0,47}$`). Lookback days now also validate inline (1-90, integer only) instead of silently coercing 0 to 7. - **Preserve config on error** (aws#16): when the launch failed, hitting "Go back" reset the wizard to the Source step and discarded all selections. Now the failed config is stashed in flow state and the wizard re-opens at the Name step with everything pre-populated. - **Post-launch history** (aws#17): the wizard wrote to the job-engine store but `view insights` reads from the legacy `.cli/insights/*.json` store, so the brand-new job rendered as "No insights runs found". Mirror successful starts to the legacy store after launch. Bug bash items #4, aws#6, aws#16, aws#17 (mix of P1/P2).
agentcore-devx-automation
Bot
added
the
claude-security-reviewing
github-actions
Bot
added
the
agentcore-harness-reviewing
Package TarballHow to installgh release download pr-1602-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.20.2.tgz |
|
Claude Security Review: no high-confidence findings. (run) |
agentcore-devx-automation
Bot
removed
the
claude-security-reviewing
agentcore-cli-automation
left a comment
agentcore-cli-automation
left a comment
There was a problem hiding this comment.
Nice, focused fixes for the bug bash items. Two things I'd like addressed before merge:
- The new
forwardRef/useImperativeHandle/jumpToStepsurface onRunInsightsScreenappears to be dead code — nothing in the tree passes a ref, and resume-on-error works entirely through the newinitialConfig/initialStepprops (the screen re-mounts whenRunInsightsFlowtransitions fromerrorback towizard). Either wire it up to a caller or drop it; otherwise it adds an API contract that's unused, untested, and (in React 19) unnecessary. - The two new pure validators are good candidates for a small unit test. There are no tests under
src/cli/tui/screens/run-insights/at all, and three of the four fixes here (single-agent default, inline name validation, resume-on-error) are reachable via the wizard hook + pure helpers without any TUI rendering. A smallvalidateJobName/validateLookbackInput/useRunInsightsWizardtest file would lock these in cheaply.
One smaller suggestion inline about the silent catch in persistToLegacyStore.
| ref | ||
| ) { | ||
| const wizard = useRunInsightsWizard(agentNames, initialConfig, initialStep); | ||
| useImperativeHandle(ref, () => ({ jumpToStep: wizard.jumpToStep }), [wizard.jumpToStep]); |
There was a problem hiding this comment.
This forwardRef + useImperativeHandle plumbing (and the exported RunInsightsScreenHandle / jumpToStep on the wizard hook) doesn't appear to be consumed anywhere — RunInsightsFlow mounts the screen without a ref, and resume-on-error works purely through initialConfig / initialStep. I'd suggest one of:
- Drop it — remove the
forwardRefwrapper, theRunInsightsScreenHandleinterface, theuseImperativeHandlecall, and thejumpToStepexposure fromuseRunInsightsWizard. The component goes back to a plain function and the public API stays minimal. - Wire it up — if there's a follow-up use case (e.g. surfacing field-specific errors and jumping to that step from
RunInsightsFlow), pass a ref from the flow and calljumpToStepthere so the path is exercised.
Note that with React 19, even if you do want imperative access, forwardRef is no longer needed — ref can be a regular prop.
| } | ||
| }, | ||
| [allSteps] | ||
| ); |
There was a problem hiding this comment.
jumpToStep here only exists to be threaded through useImperativeHandle in RunInsightsScreen.tsx — and nothing calls the resulting handle. Consider removing it (and the forwardRef wrapper) unless there's a planned consumer.
| // shows "No insights runs found" right after creating the job. | ||
| await persistToLegacyStore(startResult.record).catch(() => { | ||
| // Non-fatal — the job started successfully; storage failures shouldn't surface. | ||
| }); |
There was a problem hiding this comment.
Silently swallowing the error here makes it hard to diagnose a future regression where the legacy store stops being written (the user sees "No insights runs found" again and there's no breadcrumb). At minimum, log via the same mechanism the rest of the flow uses (e.g. ExecLogger or a console.warn). Since the comment already says "storage failures shouldn't surface," the goal is debuggability, not user-visible errors.
Minor: per the comment, this is a workaround until the post-launch screen reads from the job-engine store. A follow-up issue/TODO referencing that migration would help avoid leaving two stores diverging indefinitely (the engine store gets refresh updates, the legacy store doesn't — so statuses written here will stay frozen forever).
github-actions
Bot
removed
the
agentcore-harness-reviewing
jariy17
left a comment
jariy17
left a comment
There was a problem hiding this comment.
I have one blocking comment.
| // Mirror the new job to the legacy insights store so `view insights` | ||
| // (InsightsJobsScreen) finds it. Without this, the post-launch screen | ||
| // shows "No insights runs found" right after creating the job. | ||
| await persistToLegacyStore(startResult.record).catch(() => { |
There was a problem hiding this comment.
If ViewInsights is looking in the wrong directory shouldn't we change what directory it's looking at. By duplicate the job in two locations, the customer has two "sources of truth" which means we have to maintain both locations.
3 participants
Summary
Four fixes to the
agentcore run insightsinteractive wizard, from the Lens-in-CLI bug bash:Single-agent flow leaves Confirm blank. When the project has exactly one agent, the wizard skipped the agent step but never populated
config.agent, so the Confirm screen showed an emptyAgent:line. The default config now pre-populates the sole agent so it threads through to confirm and the API call.Inline name validation. The Name step accepted spaces / hyphens / leading digits and only blew up after submit with a service 400. We now validate inline using the service-side
BatchEvaluationNameshape (^[a-zA-Z][a-zA-Z0-9_]{0,47}$) fromAgentCoreEvaluationCommonModel. Lookback days also validate inline (1-90, integer only) instead of silently coercing 0 → 7.Preserve config on error. Hitting "Go back" from a launch error reset the entire wizard. The failed config is now stashed in flow state and the wizard re-opens at the Name step with all prior selections intact.
Post-launch "No insights runs found". The wizard wrote to the job-engine store, but the post-launch "View Insights Jobs" screen reads from the legacy
.cli/insights/*.jsonstore. We now mirror successful starts to the legacy store after launch so the new job appears immediately.