✨️ server: add activity and push notification on card decline by aguxez · Pull Request #622 · exactly/exa

aguxez · 2026-01-07T15:06:48Z

closes #114

Summary by CodeRabbit

New Features
- Push notifications for declined transactions and insufficient-funds events.
- Activity feed now records declined transactions and "requested" actions with status, reason, timestamps, merchant/icon, and transaction details.
- User-facing handling for frozen or non-active cards with clear responses.
Bug Fixes
- Fixed a key typo.
Tests
- Added/updated tests for declined-transaction flows, push notifications, and activity serialization.
Chores
- Version/changeset updates.

Greptile Summary

This PR wires up activity-feed entries and push notifications for declined card transactions. When Panda delivers a requested webhook for a frozen/inactive card, or when a created/updated webhook carries status: "declined", the new reject() helper inserts (or appends to) a transaction record with a zero-hash placeholder and sends a targeted push notification for recognized decline reasons (insufficient_funds, merchant_blocked, frozen_card). The PandaActivity schema is extended to parse these records on the activity-feed API side.

Key changes:

New reject() function in panda.ts uses PostgreSQL jsonb_set to append declined bodies to existing transaction rows and gates push notifications via xmax = 0 (first-insert detection).
PandaActivity transformer normalizes "requested" to "created" and spreads status/reason onto the output when a declined body is found; the settled field is removed (no consumers found in the codebase).
Frozen-card and non-active card states now receive distinct trackAuthorizationRejected calls in the requested handler; only the frozen-card path calls reject().
captureException context for bad transactions is improved by flattening valibot issues instead of passing raw parse objects.

Issues found:

mapped.find(b => b.status === "declined") picks the first declined body, so when multiple declined entries accumulate for the same transaction (e.g., a created decline followed by an updated decline with a different reason), the stale earlier reason is shown to the user. findLast would show the most recent.
reject() is called in the generic unexpected-error path (line 469) regardless of whether the error was issuing-network related. Any unhandled server error will produce a reason: "transaction declined" activity record that is indistinguishable from a real network decline to the user, though no push notification is sent.

Confidence Score: 3/5

Mostly safe to merge with two moderate logic issues: stale decline reasons shown to users and misleading "transaction declined" entries for server errors.
The core notification and activity-feed logic is solid with good test coverage. However, two verified logic issues warrant attention: (1) find() instead of findLast() will surface stale decline reasons when multiple declines accumulate for a transaction, and (2) unexpected server errors now create permanent "transaction declined" activity records indistinguishable from real declines to users. Neither causes data loss or security issues, but both degrade UX and observability. The issues are straightforward to fix and should be addressed before or immediately after merge.
server/api/activity.ts (findLast fix) and server/hooks/panda.ts (unexpected-error handling)

Sequence Diagram

sequenceDiagram
    participant Panda
    participant Hook as panda.ts hook
    participant DB as transactions DB
    participant Push as Push Notification

    Panda->>Hook: POST requested (card spend attempt)
    Hook->>DB: query card by id (fetch status)
    alt card FROZEN
        Hook->>DB: reject() → INSERT/APPEND declined body (frozen_card)
        Hook->>Push: sendDeclinedNotification (if isNew)
        Hook-->>Panda: 403 frozen card
    else card not ACTIVE
        Hook-->>Panda: 403 card not active (no reject() call)
    else card ACTIVE
        Hook->>Hook: risk assess + prepareCollection
        alt PandaError (e.g. InsufficientAccountLiquidity)
            Hook->>DB: reject() → INSERT/APPEND declined body
            Hook->>Push: sendDeclinedNotification (if isNew & notify)
            Hook-->>Panda: 557 error code
        else unexpected error
            Hook->>DB: reject() → INSERT/APPEND declined body (reason: "transaction declined")
            Hook-->>Panda: 569 ouch
        else success
            Hook-->>Panda: 200 ok
        end
    end

    Panda->>Hook: POST created/updated (status: declined)
    Hook->>DB: await reject() → INSERT/APPEND declined body
    Hook->>Push: sendDeclinedNotification (if isNew & notify)
    Hook-->>Panda: 200 ok

    note over DB,Push: isNew = (xmax = 0) — only first insert fires notification

_{Last reviewed commit: dd260a8}

changeset-bot · 2026-01-07T15:06:52Z

🦋 Changeset detected

Latest commit: 660c18a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@exactly/server	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

coderabbitai · 2026-01-07T15:07:01Z

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

▶️ Resume reviews
🔍 Trigger review

Walkthrough

Adds server-side decline handling: classifies decline reasons, persists declined transaction bodies, routes frozen/non-active/error flows through new decline handlers, triggers push notifications for select decline types, extends activity schema to include "requested"/declined fields, and adds tests for declines and notifications.

Changes

Cohort / File(s)	Summary
Changesets `.changeset/honest-peas-stand.md`, `.changeset/six-dancers-hang.md`	Add two changeset files bumping `@exactly/server` (patch); metadata only.
Decline Handling Core `server/hooks/panda.ts`	Add DECLINE_REASONS and NOTIFICATION_TRIGGERING_REASONS; new helpers (`getDeclineReason`, `handleDeclinedTransaction`, `updateTransactionRecord`, `sendDeclinedNotification`, `handleRejectedTransaction*`); integrate decline flow for requested/created/error paths; persist declined bodies; handle frozen/non-active card flows and route errors through decline handlers.
Activity Schema & Transform `server/api/activity.ts`	Extend PandaActivity bodies to accept `requested`, optional `status`/`reason`, nested `body.spend` with `enrichedMerchantIcon`; normalize "requested" to "created"; propagate merchant icon and single timestamp; add declined-path shaping. CardActivity action set now includes `requested`.
Decline & Notification Tests `server/test/hooks/panda.test.ts`	Add OneSignal import and push-notification tests; replace balance checks with `maxWithdraw`; safer transaction receipt handling; insert declined-transaction fixtures and assert appended bodies and pushes.
Activity Tests `server/test/api/activity.test.ts`	Add `httpSerialize`/`removeUndefined` helpers; refactor logs/borrows gathering; adjust test payload shapes and assertions to use serialized comparisons.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant CardSystem as Card System
    participant PandaHook as Panda Hook
    participant DB as Database
    participant Notif as Notification Service

    Client->>CardSystem: submit transaction
    CardSystem->>PandaHook: webhook / payload
    PandaHook->>DB: fetch card & transaction
    alt card FROZEN or not ACTIVE
        DB-->>PandaHook: card status != ACTIVE
        PandaHook->>PandaHook: getDeclineReason()
        PandaHook->>PandaHook: handleRejectedTransactionSync()
        PandaHook-->>CardSystem: 403 / decline response
    else processing error or explicit decline
        PandaHook->>PandaHook: getDeclineReason()
        PandaHook->>DB: updateTransactionRecord(...) with declined body
        DB-->>PandaHook: OK
        PandaHook->>PandaHook: handleDeclinedTransaction()
        PandaHook->>Notif: sendDeclinedNotification()
        Notif-->>Client: push notification delivered
    else success
        PandaHook-->>CardSystem: success response
    end

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

🥅 server: fingerprint keeper errors for sentry grouping #743 — Modifies error-handling in server/hooks/panda.ts, touching contract error/fingerprint and error paths (closely related).
🥅 server: handle misc panda errors from sentry #736 — Changes server/hooks/panda.ts and panda notification/test flows (overlaps decline/notification logic).

Suggested reviewers

nfmelendez
cruzdanilo
franm91

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title accurately describes the main changes: adding activity tracking and push notification functionality for card decline events.
Linked Issues check	✅ Passed	The PR addresses both objectives from issue `#114`: storing activity records on card decline and sending push notifications on specific decline reasons.
Out of Scope Changes check	✅ Passed	All changes are within scope: core decline handling in panda.ts, activity API expansion in activity.ts, and corresponding tests. Two changeset files document the changes appropriately.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch card-declined-events

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 and usage tips.}

gemini-code-assist · 2026-01-07T15:07:06Z

Summary of Changes

Hello @aguxez, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the server's transaction handling by introducing a mechanism to process declined card transactions. The immediate user-facing change is the implementation of push notifications, which will inform users instantly about rejected purchases. Although the foundational code for recording these declined transactions as user activity has been added, this specific database logging functionality is temporarily disabled, pending the development of corresponding user interface elements.

Highlights

New Transaction Handling: Implemented a new handleDeclinedTransaction function to process card rejections within the panda hook.
Push Notifications for Declines: Enabled push notifications for users when their card transactions are declined, providing immediate feedback on rejected purchases.
Deferred Activity Logging: Prepared the server-side logic for logging declined transactions as activity in the database, though this feature is currently commented out and awaiting UI implementation.
Test Coverage for Future Features: Added it.todo test cases to cover the future enablement of declined transaction activity logging, ensuring proper functionality once the UI is ready.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

coderabbitai

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In @server/hooks/panda.ts:
- Around line 955-998: Remove the large commented-out DB logic inside
handleDeclinedTransaction and track the work in your issue tracker: create an
issue describing the pending UI changes needed to handle declined transactions
and include its ID; then replace the commented block with a single-line comment
in handleDeclinedTransaction referencing that issue (e.g., "See ISSUE-1234:
enable declined-transaction persistence once UI supports it"). Ensure the rest
of the function (push notification and error capture) remains unchanged.
- Line 965: Replace the existing comment "// TODO: Enable once UI has proper
designs to handle declined transactions in activity" with the coding-guideline
compliant format: use uppercase tag, a single space, and a fully lowercase
comment body (e.g. "// TODO enable once ui has proper designs to handle declined
transactions in activity"); update the line containing that TODO comment in the
server/hooks/panda.ts hook to remove the colon and capitalize only the TODO tag.

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0860357 and 118a340.

📒 Files selected for processing (3)

.changeset/honest-peas-stand.md
server/hooks/panda.ts
server/test/hooks/panda.test.ts

🧰 Additional context used

📓 Path-based instructions (7)

**/.changeset/*.md

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

Use a lowercase sentence in the imperative present tense for changeset summaries

Files:

.changeset/honest-peas-stand.md

server/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/server.mdc)

server/**/*.ts: Use c.var object to pass strongly-typed data between Hono middleware and route handlers; do not use c.set
All request validation (headers, body, params) must be handled by @hono/valibot-validator middleware; do not perform manual validation inside route handlers
Use Hono's built-in error handling by throwing new HTTPException() for expected errors; unhandled errors will be caught and logged automatically
Enforce Node.js best practices using ESLint plugin:n/recommended configuration
Enforce Drizzle ORM best practices using ESLint plugin:drizzle/all configuration, including requiring where clauses for update and delete operations
Use Drizzle ORM query builder for all database interactions; do not write raw SQL queries unless absolutely unavoidable
All authentication and authorization logic must be implemented in Hono middleware
Do not access process.env directly in application code; load all configuration and secrets once at startup and pass them through dependency injection or context
Avoid long-running, synchronous operations; use async/await correctly and be mindful of CPU-intensive tasks to prevent blocking the event loop

Files:

server/hooks/panda.ts
server/test/hooks/panda.test.ts

**/*.{js,ts,tsx,jsx,sol}

📄 CodeRabbit inference engine (AGENTS.md)

Follow linter/formatter (eslint, prettier, solhint) strictly with high strictness level. No any type.

Files:

server/hooks/panda.ts
server/test/hooks/panda.test.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Omit redundant type names in variable declarations - let the type system explain itself

**/*.{ts,tsx}: Use PascalCase for TypeScript types and interfaces
Use valibot for all runtime validation of API inputs, environment variables, and other data; define schemas once and reuse them
Infer TypeScript types from valibot schemas using type User = v.Input<typeof UserSchema> instead of manually defining interfaces

Files:

server/hooks/panda.ts
server/test/hooks/panda.test.ts

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{ts,tsx,js,jsx}: Omit contextual names - don't repeat class/module names in members
Omit meaningless words like 'data', 'state', 'manager', 'engine', 'value' from variable and function names unless they add disambiguation

**/*.{ts,tsx,js,jsx}: Prefer function declarations for all multi-line functions; use function expressions or arrow functions only for single-line implementations
Prefer const for all variable declarations by default; only use let if the variable's value will be reassigned
Declare each variable on its own line with its own const or let keyword, not multiple declarations on one line
Use camelCase for TypeScript variables and functions
Always use import type { ... } for type imports
Use relative paths for all imports within the project; avoid tsconfig path aliases
Follow eslint-plugin-import order: react, external libraries, then relative paths
Use object and array destructuring to access and use properties
Use object method shorthand syntax when a function is a property of an object
Prefer optional chaining (?.), nullish coalescing (??), object and array spreading (...), and for...of loops over traditional syntax
Do not use abbreviations or cryptic names; write out full words like error, parameters, request instead of err, params, req
Use Number.parseInt() instead of the global parseInt() function when parsing numbers
All classes called with new must use PascalCase
Use Buffer.from(), Buffer.alloc(), or Buffer.allocUnsafe() instead of the deprecated new Buffer()
Use @ts-expect-error instead of @ts-ignore; follow it immediately with a single-line lowercase comment explaining why the error is expected, without separators like - or :
Do not include the type in a variable's name; let the static type system do its job (e.g., use const user: User not const userObject: User)
Do not repeat the name of a class or module within its members; omit contextual names (e.g., use `class User { getProfil...

Files:

server/hooks/panda.ts
server/test/hooks/panda.test.ts

server/**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

server/**/*.{ts,tsx}: Server API: implement schema-first approach using OpenAPI via hono with validation via valibot middleware
Server database: drizzle schema is source of truth. Migrations required. No direct database access in handlers - use c.var.db

Files:

server/hooks/panda.ts
server/test/hooks/panda.test.ts

**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/style.mdc)

For files with a single default export, name the file identically to the export; for files with multiple exports, use camelCase with a strong preference for a single word

Files:

server/hooks/panda.ts
server/test/hooks/panda.test.ts

🧠 Learnings (2)

📚 Learning: 2025-12-31T00:23:55.034Z

Learnt from: cruzdanilo
Repo: exactly/exa PR: 610
File: .changeset/ready-experts-fly.md:1-2
Timestamp: 2025-12-31T00:23:55.034Z
Learning: In the exactly/exa repository, allow and require empty changeset files (containing only --- separators) when changes are not user-facing and do not warrant a version bump. This is needed because CI runs changeset status --since origin/main and requires a changeset file to exist. Ensure such empty changesets are used only for non-user-facing changes and document the rationale in the commit or changelog notes.

Applied to files:

.changeset/honest-peas-stand.md

📚 Learning: 2025-12-23T19:58:16.574Z

Learnt from: CR
Repo: exactly/exa PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-23T19:58:16.574Z
Learning: Zero config local dev environment: no `.env` files, mock all external services

Applied to files:

server/test/hooks/panda.test.ts

🧬 Code graph analysis (2)

server/hooks/panda.ts (1)

server/utils/onesignal.ts (1)

sendPushNotification (7-25)

server/test/hooks/panda.test.ts (1)

server/database/schema.ts (1)

transactions (36-43)

🔇 Additional comments (5)

server/test/hooks/panda.test.ts (2)

2-2: LGTM!

Import adjustments for mocks are clean and improve organization.

Also applies to: 7-7

1352-1439: Test stubs properly scaffolded for future implementation.

The two test cases for declined transaction handling are well-structured and align with the commented-out database logic in server/hooks/panda.ts. Using it.todo is appropriate while waiting for UI designs.

server/hooks/panda.ts (2)

533-533: LGTM!

The call to handleDeclinedTransaction is correctly placed after the mutex is released, and the type cast is necessary due to TypeScript's union type handling.

988-998: LGTM!

Push notification implementation properly formats the transaction details and includes error handling consistent with the rest of the codebase.

.changeset/honest-peas-stand.md (1)

1-5: LGTM!

Changeset properly documents the feature addition with appropriate version bump and clear description.

sentry · 2026-01-07T18:21:48Z

Codecov Report

❌ Patch coverage is 62.29508% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.10%. Comparing base (e76f034) to head (660c18a).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
server/hooks/panda.ts	58.62%	9 Missing and 3 partials ⚠️
server/api/activity.ts	65.62%	6 Missing and 5 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #622      +/-   ##
==========================================
+ Coverage   71.96%   72.10%   +0.13%     
==========================================
  Files         229      229              
  Lines        8389     8513     +124     
  Branches     2713     2760      +47     
==========================================
+ Hits         6037     6138     +101     
- Misses       2121     2132      +11     
- Partials      231      243      +12

Flag	Coverage Δ
e2e	`71.38% <62.29%> (-0.13%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

devin-ai-integration

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 4 additional flags.

nfmelendez · 2026-04-17T14:05:33Z

@coderabbitai what would happen if for the same transaction the webhook get the transaction created declined before the transaction requested. show me an example of how the row in the db will be.

coderabbitai · 2026-04-17T14:07:12Z

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get the full panda.ts hook
cat server/hooks/panda.ts

# Also look at the DB schema
fd -e ts schema --exec cat {}

Length of output: 52959

@nfmelendez Here's a deep analysis of the out-of-order scenario.

Out-of-Order Flow: `created declined` → `requested`

Step 1 — `created declined` arrives first

The code enters the case "created" branch, detects payload.body.spend.status === "declined", and calls reject().

The reject() function does an INSERT ... ON CONFLICT DO UPDATE and uses xmax = 0 to detect if it's a brand-new row:

INSERT INTO transactions (id, card_id, hashes, payload)
VALUES ('txn_abc123', 'card_xyz', ARRAY['0x000...0'], '{"type":"panda","bodies":[...]}')
ON CONFLICT (id) DO UPDATE SET
  hashes = transactions.hashes || ARRAY['0x000...0']::text[],
  payload = jsonb_set(payload, '{bodies}', bodies || new_body)
RETURNING xmax = 0 AS is_new

Since this is the first event, isNew = true → 🔔 notification is sent (for notify: true reasons like merchant_blocked, insufficient_funds, frozen_card).

DB row after step 1:

{
  "id": "txn_abc123",
  "card_id": "card_xyz",
  "hashes": ["0x0000000000000000000000000000000000000000000000000000000000000000"],
  "payload": {
    "type": "panda",
    "bodies": [
      {
        "id": "evt_001",
        "resource": "transaction",
        "action": "created",
        "body": {
          "id": "txn_abc123",
          "type": "spend",
          "spend": {
            "amount": 1500,
            "currency": "usd",
            "status": "declined",
            "declinedReason": "merchant_blocked",
            "merchantName": "SomeMerchant",
            "localAmount": 1500,
            "localCurrency": "usd"
          }
        },
        "createdAt": "2026-01-15T10:00:01.000Z",
        "status": "declined",
        "reason": "merchant blocked"
      }
    ]
  }
}

Step 2 — `requested` arrives second (same transaction)

The code enters case "requested". There is no early-exit check against the DB to see whether this transaction is already declined. It proceeds as if it's a fresh authorization.

This leads to two possible sub-scenarios:

Sub-scenario A: `requested` authorization succeeds → returns 200 OK

The code calls prepareCollection → traceClient.traceCall() → returns authorize() (i.e., c.json({ code: "ok" })).

No DB write happens. The row in the DB is unchanged from Step 1. However, Exa just approved an authorization for a transaction that Panda had already declined at the network level — the response is effectively ignored by Panda, but it's logically inconsistent.

DB row: unchanged (same as Step 1)

Sub-scenario B: `requested` authorization fails (e.g., `PandaError`)

The catch block calls reject(account, payload, jsonBody, error.message) again. This time, the INSERT ... ON CONFLICT DO UPDATE hits the conflict path (row already exists). xmax = 0 returns false → no duplicate notification is sent ✅.

The row gets a second zeroHash appended to hashes and a second body appended to bodies.

DB row after step 2B:

{
  "id": "txn_abc123",
  "card_id": "card_xyz",
  "hashes": [
    "0x0000000000000000000000000000000000000000000000000000000000000000",
    "0x0000000000000000000000000000000000000000000000000000000000000000"
  ],
  "payload": {
    "type": "panda",
    "bodies": [
      {
        "action": "created",
        "status": "declined",
        "reason": "merchant blocked",
        "createdAt": "2026-01-15T10:00:01.000Z"
      },
      {
        "action": "requested",
        "status": "declined",
        "reason": "insufficient funds",
        "createdAt": "2026-01-15T10:00:02.000Z"
      }
    ]
  }
}

⚠️ Key Issues Identified

Issue	Details
No idempotency guard on `requested`	The `requested` handler doesn't check if the transaction row already exists as `declined` before attempting authorization. It will process the request and potentially approve it.
Duplicate `zeroHash` in `hashes[]`	In sub-scenario B, the same `zeroHash` is appended twice. Any downstream logic that counts hashes or iterates over them will see two entries for the same conceptual decline.
`activity.ts` disambiguation	The `PandaActivity` transform in `server/api/activity.ts` checks for `body.action === "created"` to detect a force-capture in `prepareCollection`. With two bodies of different actions, this check could behave unexpectedly.
No notification for sub-scenario A	If `requested` succeeds, no activity body is appended, so the only DB record is from the `created declined` event — this is actually correct, but the silent approval response to Panda is a logical oddity.

The notification deduplication via xmax = 0 is solid — no double notification will fire. The main concern is the lack of an early-exit in the requested handler when the transaction is already recorded as declined.

🧠 Learnings used

Learnt from: aguxez
Repo: exactly/exa PR: 898
File: server/hooks/persona.ts:270-272
Timestamp: 2026-03-20T15:09:09.813Z
Learning: In `server/hooks/persona.ts`, within the `cardLimit` webhook handler, returning HTTP 200 with `{ code: "no panda" }` or `{ code: "no credential" }` when `pandaId` is absent or no credential is found is intentionally safe. The business invariant guarantees that a card can only exist after KYC (pandaId) is set, so there is no active card to update in those cases and no retry is needed.

Learnt from: mainqueg
Repo: exactly/exa PR: 637
File: server/hooks/persona.ts:186-195
Timestamp: 2026-01-15T19:06:45.697Z
Learning: In server/hooks/persona.ts, the webhook handler has intentionally different error handling for Manteca vs Panda flows: the Manteca path (payload.template === "manteca") lets addDocument errors propagate to enable webhook retries, while the Panda path uses .catch() to swallow addDocument errors and prevent retries since the user creation is already committed.

sentry · 2026-04-20T08:49:46Z

+          {
+            ...bodies[index],
+            forceCapture: bodies[index]?.action === "completed" && !bodies.some((b) => b.action === "created"),
+            type,
+            hash,
+            events: borrow?.events,
+            blockTimestamp: borrow?.timestamp,
+          },
+        );
+        if (validation.success) return validation.output;
+        throw new Error("bad panda activity");


Bug: Declined 'requested' transactions without a body.id are silently filtered out of the activity feed due to a schema validation mismatch, making them invisible to the user.
_{Severity: HIGH}

Suggested Fix

In the reject() function, when creating declinedBody, ensure body.id is always present. Use the existing fallback logic (payload.body.id ?? payload.id) to get a transaction ID and explicitly set it on declinedBody.body.id if it was originally missing. This will ensure the data conforms to the CardActivity schema upon read.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: server/api/activity.ts#L558-L568 Potential issue: The schema for a 'requested' transaction allows `payload.body.id` to be optional. When such a transaction is declined (e.g., on a frozen card), the system stores the transaction body without an `id`. However, the activity feed parser (`CardActivity`) requires `body.id`. This causes a validation failure in `PandaActivity.transform()`, which is silently caught and results in the declined transaction being filtered out of the user's activity feed. This leads to a silent data loss for the user, as the declined transaction record is never displayed.

aguxez requested review from cruzdanilo and nfmelendez as code owners January 7, 2026 15:06