Skip to content

fix(web): show pending usage reset credit feedback - #17882

Open
GabrielCoelhoCruz wants to merge 1 commit into
pingdotgg:mainfrom
GabrielCoelhoCruz:fix/usage-reset-credit-feedback
Open

GabrielCoelhoCruz wants to merge 1 commit into
pingdotgg:mainfrom
GabrielCoelhoCruz:fix/usage-reset-credit-feedback

Conversation

@GabrielCoelhoCruz

Copy link
Copy Markdown

Problem

In Usage → Limits, confirming a reset credit closes the popover and confirmation before the request finishes. The pending button disappears, and the page shows no feedback until the result arrives.

Closes #17449.

Change

Show "Using reset credit…" in the existing status region outside the popover. Keep the result visible when the last available credit disappears.

Bind confirmation, pending text, and results to the account identity. Share the pending guard across controls for the same redemption target, so repeated confirmation cannot attach another account to an old request.

Scope and approval

This is a focused fix for an obvious defect in an existing confirmed action, under the bug-fix exception in CONTRIBUTING.md. The account identity and duplicate guard belong to that same pending operation. Confirmation, cancellation, permissions, eligibility, RPC payloads, and backend redemption rules stay in place.

This covers #17449 only. It does not include preview keyboard changes from #17733 or PR #15035. PRs #17222 and #17705 touch some of the same usage files but address quota grouping and credit balances. This change does not implement those features.

Verification

  • Behavioral tests were written before production changes. The clean baseline had 8 failures and 5 passes. The candidate passed all 13 interaction cases and 40 existing shared cases, including account changes, late replies, pending feedback, cancellation, duplicate attempts, success, and error.
  • The existing single-flight test passed. Changed-file lint, web and shared typechecks, and git diff --check passed on current main. Shared typecheck emits an existing advisory in src/symlink.ts.
  • Ego Browser exercised the isolated web/server stack with a synthetic Codex executable. Cancel, confirm, pending display, reopening with the action disabled, error, and success passed. Success refreshed both limits and kept the result after spending the last credit.

The external Codex service was replaced by a local protocol fixture. No real credit was redeemed. Account switching has behavioral test coverage, not an integrated account-switch check. Native desktop and mobile were not run. The videos sample the actual page and preserve capture timing.

Exact commands, tested revisions, and limitations

Before, request pending After, request pending
No feedback after dialogs close Pending feedback remains visible

Before recording · After recording

Models used were GPT-6-Astra for implementation, GPT-6-Sol for independent review, and GPT-6.1-Sol for verification, through the Codex harness in T3 Code.

@github-actions github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Oct 10, 2026
@macroscopeapp

macroscopeapp Bot commented Oct 10, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: Approved at 1335bf9

Macroscope's review found this PR approvable — This is a focused fix to an existing reset-credit interaction, keeping pending and result feedback visible while preventing duplicate in-flight requests. The substantial diff is primarily interaction-test coverage, with no backend, schema, deployment, authentication, or billing logic changes.

You can add or adjust custom eligibility rules. Learn more.

@coderabbitai

coderabbitai Bot commented Oct 10, 2026

Copy link
Copy Markdown

Review in Change Stack →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Configuration used: Path: .coderabbit.config.ts
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: c3078f53-2998-4e8c-8458-41ca522dabe9

📥 Commits

Reviewing files that changed from the base of the PR and between 50647de and 1335bf9.


📒 Files selected for processing (6)
  • apps/web/src/components/chat/ComposerUsageLimits.tsx
  • apps/web/src/components/usage/UsageLimits.tsx
  • apps/web/src/components/usage/UsageLimitsPooled.test.tsx
  • apps/web/src/components/usage/UsageLimitsPooled.tsx
  • packages/shared/src/usageLimits.test.ts
  • packages/shared/src/usageLimits.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.



📝 Walkthrough

Walkthrough

The change adds stable account identities to usage-limit records and uses them to scope reset-credit confirmation, status, and shared pending state. Pooled usage segments display redemption progress, block duplicate or unauthorized redemption, and retain outcomes across popover and account changes.

Changes

Reset-credit redemption

Layer / File(s) Summary
Account identity and propagation
packages/shared/src/usageLimits.ts, packages/shared/src/usageLimits.test.ts, apps/web/src/components/chat/ComposerUsageLimits.tsx
LimitAccount now includes an identity. Native and hub accounts derive it from resolved account keys or fallbacks. The chat composer passes an identity derived from environment, account, normalized email, and credential fingerprint.
Redemption state and pooled feedback
apps/web/src/components/usage/UsageLimits.tsx, apps/web/src/components/usage/UsageLimitsPooled.tsx, apps/web/src/components/usage/UsageLimitsPooled.test.tsx
useResetCredit tracks confirmation, pending requests, and outcomes by identity and target. The pooled UI shows “Using…” for the redeeming identity and disables actions while busy or unauthorized. Tests cover duplicate requests, identity changes, permissions, and redemption outcomes.

Priority: ➖ Normal

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

Change: Bug fix

Suggested reviewers: juliusmarminge, maria-rcks

Fixed issue severity: <fixed_issue_severity>Low</fixed_issue_severity>


Merge Risk | ⚪ Minimal · up to 1335b

Merge Risk: ⚪ Minimal · up to 1335b

The change adds visible "Using reset credit…" feedback and scopes redemption state to the account. No concrete merge-blocking risk was identified in the supplied context.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 1335b

The change preserves the existing confirmation and permission requirements while improving duplicate-request protection and account-specific feedback. No introduced security flaw was established. Remaining uncertainty concerns recovery after connection interruption and identity edge cases, not broader access or authority.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

  • inferred — A redemption still selects one environment and one provider or source-account target, rather than broadcasting across the pooled view. Effects belong to the underlying provider account and may therefore be visible wherever that account is shared; hub redemption can also clear that account's routing cooldown.

Trust Boundaries and Controls

  • observed — Client identity does not cross into backend target selection. The existing RPC requires provider-management scope; native dispatch rejects missing, disabled, or unsupported instances, and source redemption requires an enabled source with a management key. These backend controls are unchanged in the full PR comparison.

Resilience and Maintainability Implications

  • observed — The new shared pending entry is removed when the command settles, and listener subscriptions have unsubscribe cleanup. Existing native coordination retains an idempotency key after ambiguous failure, while source redemption derives a stable request ID from account and credit. These controls do not establish universal exactly-once execution or prove that every interrupted transport settles the client promise.

Pre-merge checks | Passed 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check Passed The title clearly and concisely describes the main change: showing feedback while a usage reset credit request is pending.
Description check Passed The description includes all required sections. It explains the problem, the change, scope and approval basis, focused verification results, limitations, UI evidence, and the models and harness used.
Linked Issues check Passed Issue [#17449] requires visible progress from confirmation until the reset result appears. useResetCredit stores pending redeems by target and returns Using reset credit… for the initiating accoun…
Out of Scope Changes check Passed The changes remain within issue [#17449]. The account identity, shared pending guard, target binding, and LimitAccount.identity support correct feedback and duplicate protection for the same reset o…

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR

  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L 100-499 changed lines (additions + deletions). vouch:unvouched PR author is not yet trusted in the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Using a reset credit from the pooled usage bar shows no progress while it runs

1 participant