Skip to content

fix(chat): render resolved permission outcomes instead of generic Continued - #2132

Open
zhangmo8 wants to merge 5 commits into
devfrom
fix/permission-outcome-rendering
Open

fix(chat): render resolved permission outcomes instead of generic Continued#2132
zhangmo8 wants to merge 5 commits into
devfrom
fix/permission-outcome-rendering

Conversation

@zhangmo8

@zhangmo8 zhangmo8 commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Closes #2117

Summary

Resolved tool-permission action blocks previously rendered the generic checkmark + "Continued" label regardless of the persisted outcome, so a denial could look successful. The renderer now faithfully projects the broker-owned decision (block.status = 'granted' | 'denied') and merges it into the associated tool card.

  • displayMessage.ts: new getResolvedPermissionStatus() and buildResolvedPermissionStatusByToolCallId() helpers; the map only includes permission blocks whose tool card exists in the same message.
  • MessageItemAssistant.vue: resolved permission action blocks with a matching tool card are no longer rendered as a separate card; their outcome is passed to MessageBlockToolCall via the new permissionStatus prop. Missing-tool-card cases fall back to a compact standalone label.
  • MessageBlockToolCall.vue: renders an Allowed (emerald) / Denied (red) badge on the tool pill, styled like the existing RTK badge.
  • MessageBlockActivityGroup.vue: forwards the permission map so tool cards inside collapsed activity groups show the badge too.
  • MessageBlockAction.vue: fallback rendering uses shield-check "Permission granted" / shield-x "Permission denied" (existing i18n keys) instead of "Continued". Rate-limit, legacy needContinue and other action types keep their behavior.
  • i18n: added toolCall.badge.allowed / toolCall.badge.denied to all 20 locales.

Layout

BEFORE                          AFTER (grant)                  AFTER (deny)
[check] Continued               [run_command  Allowed >]       [run_command  Denied >]
[run_command  >]  Completed

Acceptance criteria

  • Granted requests render as Allowed/Granted, never Continued
  • Denied requests render as Denied and cannot appear successful
  • The status is associated with the correct tool call (matched by tool_call.id)
  • Pending permissions remain actionable and accessible (overlay flow untouched)
  • Question actions and legacy continue actions retain their distinct semantics
  • Renderer tests cover pending, granted, denied, read-only, and missing-tool-card fallbacks

Verification

  • vitest run test/renderer/components/message — 16 files, 151 tests passed
  • pnpm run typecheck, pnpm run lint, pnpm run format, pnpm run i18n all pass

Summary by CodeRabbit

  • New Features

    • Tool-call cards and activity history now display clear “Allowed” or “Denied” permission badges with status-specific icons and colors.
    • Permission outcomes appear directly on standard and live tool-call cards.
    • Pending or unmatched permission requests remain visible without misleading resolution labels.
  • Localization

    • Added translated permission-status labels across supported languages.
  • Tests

    • Added coverage for granted, denied, pending, unmatched, read-only, live, and error-state permission displays.

@coderabbitai

coderabbitai Bot commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5d654878-aa32-4f3d-96de-2f377095b77a

📥 Commits

Reviewing files that changed from the base of the PR and between 069a389 and 88a1691.

⛔ Files ignored due to path filters (2)
  • src/renderer/src/lib/icons/icon-collections.generated.ts is excluded by !**/*.generated.*
  • src/renderer/src/lib/icons/icon-whitelist.generated.ts is excluded by !**/*.generated.*
📒 Files selected for processing (6)
  • .github/workflows/prcheck.yml
  • src/renderer/src/components/message/LiveDelegationToolCallCard.vue
  • src/renderer/src/components/message/MessageBlockToolCall.vue
  • src/types/i18n.d.ts
  • test/renderer/components/message/MessageBlockToolCall.test.ts
  • test/renderer/components/message/MessageItemAssistant.test.ts
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/renderer/src/components/message/MessageBlockToolCall.vue
  • test/renderer/components/message/MessageItemAssistant.test.ts

📝 Walkthrough

Walkthrough

The renderer now resolves granted and denied tool permission actions, associates them with matching tool calls, hides redundant resolved action blocks, and displays localized permission statuses in action and tool-call components. Tests cover resolved, pending, unmatched, denied, and read-only cases.

Changes

Permission outcome rendering

Layer / File(s) Summary
Resolve and project permission outcomes
src/renderer/src/features/chat-page/model/displayMessage.ts, src/renderer/src/components/message/MessageItemAssistant.vue, src/renderer/src/components/message/MessageBlockActivityGroup.vue
Permission blocks now resolve to granted or denied statuses for matching tool calls. Matching resolved action blocks are filtered from assistant message rendering.
Render localized permission states
src/renderer/src/components/message/MessageBlockAction.vue, src/renderer/src/components/message/MessageBlockToolCall.vue, src/renderer/src/components/message/LiveDelegationToolCallCard.vue, src/renderer/src/i18n/*/toolCall.json, src/types/i18n.d.ts
Action blocks, tool-call triggers, and live-delegation cards display localized allowed or denied states with status-specific presentation.
Validate permission rendering
test/renderer/components/message/MessageBlockBasics.test.ts, test/renderer/components/message/MessageBlockToolCall.test.ts, test/renderer/components/message/MessageItemAssistant.test.ts
Tests cover resolved, pending, unmatched, denied, read-only, standard tool-call, and live-delegation cases.

Renderer test infrastructure

Layer / File(s) Summary
Increase renderer test heap
.github/workflows/prcheck.yml
The renderer test job sets the Node.js maximum heap size to 6144 MB.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related PRs

Suggested reviewers: yyhhyyyyyy

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Out of Scope Changes check ⚠️ Warning The PR includes unrelated locale declaration keys and a CI heap-limit change beyond the linked issue's product requirements. Move unrelated i18n declaration updates and the CI heap-limit change into separate pull requests, unless they are required for this fix.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes replacing generic Continued rendering with resolved permission outcomes.
Linked Issues check ✅ Passed The changes implement granted and denied rendering, tool-call association, pending preservation, fallbacks, localization, and targeted tests.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/permission-outcome-rendering

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/renderer/src/components/message/MessageItemAssistant.vue`:
- Around line 92-96: Pass the resolved permission status from
permissionStatusByToolCallId to the MessageBlockToolCall invocation used for
mcp-app/app-only tool calls, matching the existing normal tool-call prop
behavior and using the tool-call ID lookup. Add a regression test covering a
resolved permission action paired with an app-only tool call and verify its
permission outcome renders.

In `@test/renderer/components/message/MessageItemAssistant.test.ts`:
- Around line 786-808: Add a regression case alongside the existing permission
outcome tests using two tool calls with distinct IDs and one resolved permission
action targeting one ID. Assert that only the matching tool-call stub receives
the expected permissionStatus, while the other remains unset, using the existing
mountWith, createPermissionActionBlock, and createToolCallBlock helpers.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: bc4b6b60-3eca-4e61-b3c4-82e7f0c26fc9

📥 Commits

Reviewing files that changed from the base of the PR and between d8f02ff and 069a389.

📒 Files selected for processing (28)
  • src/renderer/src/components/message/MessageBlockAction.vue
  • src/renderer/src/components/message/MessageBlockActivityGroup.vue
  • src/renderer/src/components/message/MessageBlockToolCall.vue
  • src/renderer/src/components/message/MessageItemAssistant.vue
  • src/renderer/src/features/chat-page/model/displayMessage.ts
  • src/renderer/src/i18n/da-DK/toolCall.json
  • src/renderer/src/i18n/de-DE/toolCall.json
  • src/renderer/src/i18n/en-US/toolCall.json
  • src/renderer/src/i18n/es-ES/toolCall.json
  • src/renderer/src/i18n/fa-IR/toolCall.json
  • src/renderer/src/i18n/fr-FR/toolCall.json
  • src/renderer/src/i18n/he-IL/toolCall.json
  • src/renderer/src/i18n/id-ID/toolCall.json
  • src/renderer/src/i18n/it-IT/toolCall.json
  • src/renderer/src/i18n/ja-JP/toolCall.json
  • src/renderer/src/i18n/ko-KR/toolCall.json
  • src/renderer/src/i18n/ms-MY/toolCall.json
  • src/renderer/src/i18n/pl-PL/toolCall.json
  • src/renderer/src/i18n/pt-BR/toolCall.json
  • src/renderer/src/i18n/ru-RU/toolCall.json
  • src/renderer/src/i18n/tr-TR/toolCall.json
  • src/renderer/src/i18n/vi-VN/toolCall.json
  • src/renderer/src/i18n/zh-CN/toolCall.json
  • src/renderer/src/i18n/zh-HK/toolCall.json
  • src/renderer/src/i18n/zh-TW/toolCall.json
  • test/renderer/components/message/MessageBlockBasics.test.ts
  • test/renderer/components/message/MessageBlockToolCall.test.ts
  • test/renderer/components/message/MessageItemAssistant.test.ts

Comment thread src/renderer/src/components/message/MessageItemAssistant.vue
Comment thread test/renderer/components/message/MessageItemAssistant.test.ts

@zerob13 zerob13 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the current head. Required GitHub checks are green, but I found one user-visible permission-history gap and one generated i18n contract drift; details are inline.

Comment thread src/renderer/src/components/message/MessageBlockToolCall.vue
Comment thread src/renderer/src/i18n/en-US/toolCall.json
@zhangmo8
zhangmo8 marked this pull request as draft August 11, 2026 03:24
@zhangmo8

Copy link
Copy Markdown
Collaborator Author

Heads-up on the extra ci: commit (88a1691): test-renderer OOM'd twice in a row on the merge ref (a straight rerun reproduced it — run). The GC log shows a single reused jsdom worker breaching the 4GB Node default heap cap (Mark-Compact 4081.2 (4106.2) → fatal). The branch itself is not the cause — the full suite passes locally on this branch alone — but dev merged several PRs with new renderer suites after this PR's last green run (#2129, #2131, #2133, #2134, #2138), and the merge-ref accumulation now crosses the 4GB line, which will start blocking other PRs' merge CIs too. Raised the job's heap ceiling to 6GB (standard 16GB runner, maxWorkers: 2). Happy to split this into its own PR if you prefer.

@zhangmo8
zhangmo8 marked this pull request as ready for review August 11, 2026 04:23
@zhangmo8
zhangmo8 requested a review from yyhhyyyyyy August 11, 2026 04:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] Render resolved permission outcomes instead of generic Continued

2 participants