TEC-58: admin-web finance/support exception cockpit#22
Conversation
- add finance exception queue state/actions backed by billing dispute signals - render dashboard finance/support section with triage actions - expand presenter/tests and update README current-state notes Co-Authored-By: Paperclip <noreply@paperclip.ing>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 54 minutes and 27 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR introduces a finance/support exception queue to the admin dashboard, adding state management types, data-fetching and triage logic, UI components for operator actions, and comprehensive test coverage across the new feature layers. Changes
Sequence DiagramsequenceDiagram
participant User as Operator
participant Page as Admin Page
participant Action as Finance Exception Action
participant API as Platform API
participant State as State Machine
User->>Page: View admin dashboard
Page->>Action: loadFinanceExceptionState(sessionToken)
Action->>API: GET /disputes?category=billing
API-->>Action: Dispute records
Action->>State: Create FinanceExceptionState.loaded
State-->>Action: State with exceptions
Action-->>Page: Return finance state
Page->>Page: Render FinanceExceptionSection with exceptions
User->>Page: Click triage action (e.g., "Follow-up")
Page->>Page: Submit form (exceptionId, actionType)
Page->>Action: triageFinanceExceptionAction(state, exceptionId, actionType)
Action->>State: Validate & locate exception
State-->>Action: Found exception
Action->>API: PATCH /disputes/{disputeId}/start-review
API-->>Action: Updated dispute
Action->>State: Update exception with new status
State-->>Action: Updated state
Action-->>Page: Return refreshed state
Page->>Page: Revalidate & re-render dashboard
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/admin-web/src/app/page.js`:
- Around line 93-97: The handler currently defaults actionType to
'routeToDispute', allowing malformed submissions to perform writes; change the
code to not default actionType (use String(formData.get('actionType') ?? '') or
simply formData.get('actionType')) and validate that actionType is one of the
allowed values ('acknowledge','followUp','routeToDispute'); if it's missing or
unknown, fail closed by returning an error/400 or throwing instead of proceeding
with the write. Locate the validation around the actionType and exceptionId
variables in the request handler and replace the defaulting behavior with an
explicit rejection on invalid/missing actionType.
- Around line 100-113: The server action currently ignores the return value of
submitFinanceExceptionTriage() and always calls revalidatePath('/'), causing
errors (queueAction.status === 'error') to be discarded; change the flow in the
handler that calls loadFinanceExceptionState and submitFinanceExceptionTriage so
you capture the returned state (e.g., const newState = await
submitFinanceExceptionTriage(...)), check newState.queueAction.status for
'error' and return that state (or throw/propagate it) instead of immediately
calling revalidatePath('/'); alternatively wire the action into the UI with
useActionState so describeFinanceExceptionQueue can render the error—ensure you
only call revalidatePath('/') on success.
In `@apps/admin-web/src/features/finance-exceptions/finance-exception-actions.ts`:
- Around line 91-102: The mapper toFinanceExceptionSummary is fabricating
participant IDs ('unknown-provider' / 'unknown-customer') which should be
nullable; change the mapping in toFinanceExceptionSummary so providerUserId and
customerUserId are set to null when the reporterRole does not match instead of
using placeholder strings, keep anomalyType/anomalyReason/disputeId mapping the
same, and ensure the FinanceExceptionSummary type (and any consumers like the
UI) treat these fields as nullable so absent parties are hidden until a proper
participant lookup enriches them.
- Around line 300-322: Both followUp and routeToDispute currently call
createStartReviewDisputeRequest/transitionDispute and produce the same state;
make them distinct by either (A) introducing a separate backend/state transition
for routing (e.g., implement createRouteToDisputeRequest(sessionToken,
disputeId) and call transitionDispute with that request so the returned dispute
or status differs, or (B) collapse the UI to a single action until the separate
transition exists. Concretely: update the routeToDispute handler (the code path
that currently calls createStartReviewDisputeRequest and transitionDispute) to
call a new request builder createRouteToDisputeRequest and/or pass a distinct
actionType (e.g., 'route' vs 'followUp') into
replaceDisputeInState/replaceDisputeInState handling so the resulting
triagingState/dispute differs; if you choose to collapse, remove one button in
the UI and unify callers to the existing createStartReviewDisputeRequest path.
🪄 Autofix (Beta)
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 7cb6e9ed-fbbb-4998-b7e7-177b58dc1fe0
📒 Files selected for processing (7)
README.mdapps/admin-web/src/app/page.jsapps/admin-web/src/features/dashboard/dashboard-presenter.test.tsapps/admin-web/src/features/dashboard/dashboard-presenter.tsapps/admin-web/src/features/finance-exceptions/finance-exception-actions.test.tsapps/admin-web/src/features/finance-exceptions/finance-exception-actions.tsapps/admin-web/src/features/finance-exceptions/finance-exception-state.ts
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Fixes Applied SuccessfullyFixed 5 file(s) based on 4 unresolved review comments. Files modified:
Commit: The changes have been pushed to the Time taken: |
Fixed 5 file(s) based on 4 unresolved review comments. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
Summary\n- add finance/support exception queue module in admin-web, derived from billing dispute signals with bounded anomaly types\n- render finance/support section on operator dashboard with loading/empty/error/loaded states and triage actions (acknowledge, follow-up, route to dispute/manual review)\n- extend dashboard presenter tests and add focused finance-exception action tests\n- update README current-state notes to reflect the new rendered capability and bounded backend seam\n\n## Verification\n- pnpm --filter @quickwerk/admin-web test\n- pnpm --filter @quickwerk/admin-web typecheck
Summary by CodeRabbit
New Features
Documentation
Tests