Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • A Ahad Mobile
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Terraform modules
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • holatech
  • Ahad Mobile
  • Merge requests
  • !161

fix(card): resolve cards stuck in processing after apply

  • Review changes

  • Download
  • Patches
  • Plain diff
Merged Hung Hoang requested to merge hunghoang/fix/card-apply-stuck-processing into develop Nov 01, 2026
  • Overview 0
  • Commits 1
  • Pipelines 1
  • Changes 2

Problem

A card created via Card → Issue stays in Processing (APPLYING) for days instead of resolving.

Task: https://hola-tech.sg.larksuite.com/record/GAb2rB3zxeRrzxcffFMlh6stg8u

Root cause

Two branches in CardIssuanceService can leave an APPLYING row forever, bypassing the 30-minute give-up:

  1. Unsubmitted card (submittedAt = null, open-fee top-up path): while the funding transfer is PENDING, advanceUnsubmitted returned early on every sweep — "nothing to give up on until it settles". A top-up the provider can never settle (e.g. a permanent refusal on an In transfer, which stays PENDING by design) kept the card Processing indefinitely.
  2. Submitted card listed with an unmappable provider status (e.g. Pending, the status seen in staging Card_update payloads): reconcileApplying called fill and returned before the give-up check, so a card the provider never activates never timed out.

Fix

Both branches now reach the give-up deadline:

  • Unsubmitted + funding PENDING past CARD_APPLY_GIVE_UP_MS → card FAILED with FUNDING_TIMEOUT, issue fee refunded (existing conditional failApplying, refund only on the winning update). The transfer itself stays with its own sweeper; a late settlement credits/reverses through the normal deposit hooks, and claimSubmit only fires on an APPLYING row, so a late APPLIED never submits a FAILED card.
  • Submitted + provider summary with unmappable status → fill still records providerStatus, then falls through to the give-up: young cards keep waiting; cards past the window fail with APPLY_TIMEOUT and refund. A summary with a mappable status (e.g. Activated) still resolves immediately, even when old.

No schema changes. Frontend needs no change: the list/detail refetch on revisit shows the resolved status, and FAILED cards already render the refund hint.

Tests

  • New regressions in card-issuance.service.spec.ts:
    • funding PENDING within the window waits; past the window → FUNDING_TIMEOUT + refund, no apply;
    • provider Pending young → stays APPLYING with providerStatus stored, no refund; past the window → APPLY_TIMEOUT + refund;
    • provider Activated past the window → fills ACTIVE, never gives up.
  • Red/green proof: with the service change reverted, the two new timeout tests fail; with it applied, all pass.
  • Full src/modules/card-account suite: 431 passed (19 Postgres-gated skipped), including sweeper and transfer suites.
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: hunghoang/fix/card-apply-stuck-processing