feat(ai): render generate_image tool calls inline, no accordion - #2019
Conversation
generate_image tool calls now bypass the generic accordion shell entirely (same dispatch path as task/agent/question tools) and always render the image inline — loading placeholder, inline error row, or the finished image. Clicking the image navigates to where it's saved in the user's Home drive instead of opening a lightbox. - tool-call-dispatch.ts gains an 'image' dispatch kind for generate_image, handled before the generic renderer/registry. - registry.tsx moves generate_image from toolRenderers into SPECIAL_HANDLED_TOOLS, which also makes it a standalone tool call (never folded into a batched ToolRunGroup). - GeneratedImageRenderer now owns all three tool-call states and navigates via usePageNavigation(pageId, driveId) on click. - image-generation-tools.ts returns driveId (already computed, was previously dropped) so the click can navigate without a lookup. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RoFf2J7TjkpBRif7rwHhdR
|
Warning Review limit reached
Next review available in: 34 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dc8c5da8f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const failed = state === 'output-error' || parsedOutput?.success === false || loadError; | ||
| const isLoading = !failed && !parsedOutput?.viewUrl; |
There was a problem hiding this comment.
Treat error-only image outputs as failures
In contexts where generate_image is invoked through execute_tool (for example Global Assistant/search-mode), wrapper failures such as invalid parameters return an output object containing error without success: false. Because failed ignores parsedOutput.error and isLoading only checks for a missing viewUrl, those completed failed calls render the loading spinner forever instead of the error message already handled below.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in ee5c6eb. Traced the exact path: execute_tool's safeParse-failure branch (execute-tool.ts) returns { error: string } with no success field at all, and dispatchToolCall resolves the effective tool name to generate_image from the input (tool_name), not the output — so GeneratedImageRenderer received that bare-error output verbatim. failed only checked success === false, and isLoading only checked for a missing viewUrl, so a completed-but-errored call spun forever instead of hitting the error row.
Fix: isLoading is now derived from whether output has arrived at all (not from viewUrl specifically), and failed now also triggers whenever output has arrived without a viewUrl (covers a bare error field or any other unexpected completed shape), in addition to the existing success === false and output-error checks.
Added regression tests in GeneratedImageRenderer.test.tsx covering: the execute_tool-shaped bare-error case, explicit success: false, the loading state, and the success/image-render state — all 4 pass. Leaving this thread open for your verification rather than auto-resolving it.
A generate_image call routed through the execute_tool wrapper (used by
search-mode/Global Assistant agents) can complete with an error-shaped
output — { error: string } — that carries no success: false field (see
execute-tool.ts's safeParse-failure and permission-denied branches).
GeneratedImageRenderer treated "no viewUrl yet" as the only loading
signal, so a completed-but-errored call spun its loading placeholder
forever instead of showing the error row.
failed now also triggers when output has arrived but has no viewUrl
(covers a bare `error` field, or any other unexpected completed shape),
and isLoading is derived from "no output yet" instead of "no viewUrl
yet". Adds regression coverage for the execute_tool-shaped error case,
the explicit success:false case, and the success/loading cases.
Addresses review feedback from PR #2019 (chatgpt-codex-connector).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RoFf2J7TjkpBRif7rwHhdR
Summary
generate_imagetool calls now bypass the generic accordion shell entirely (same dispatch path as task/agent/question tools) and always render inline — a loading placeholder while generating, an inline error row on failure, or the finished image.usePageNavigation), replacing the previous click-to-open-lightbox behavior.image-generation-tools.tsnow returnsdriveIdin the tool result (already computed bycreateImageFilePage, previously dropped) so the click can navigate without an extra lookup.Test plan
bunx tsc --noEmitclean inapps/webbunx eslintclean on all changed filesvitest run— 118 tests pass insrc/components/ai/shared/chat/, 24 pass insrc/lib/ai/tools/__tests__/image-generation-tools.test.ts(including newdriveIdassertion and newdispatchToolCallimage-kind test)generate_imageis currently admin-gated): generate an image, confirm no accordion header appears, confirm click navigates to/dashboard/<homeDriveId>/<pageId>, confirm a forced failure still renders inline without a raw JSON dump🤖 Generated with Claude Code
https://claude.ai/code/session_01RoFf2J7TjkpBRif7rwHhdR