Description
Blockchain transactions can fail due to network issues, sequence number conflicts, or Stellar network congestion. Direct fire-and-forget calls from NestJS to Soroban are not reliable enough for a healthcare application. We need a robust transaction queue with retry logic and dead letter handling.
Requirements
All Soroban contract calls must go through a BullMQ queue (soroban-tx-queue) instead of being called synchronously
Each job includes: contractMethod, args, idempotencyKey, maxRetries (default: 5)
Implement exponential backoff with jitter for retries
If a job exceeds maxRetries, move it to a dead letter queue (soroban-dlq) and emit an alert to admins
The idempotencyKey prevents duplicate on-chain submissions (checked against a Redis set before submission)
Expose a GET /blockchain/queue/status admin endpoint showing queue depth, failed jobs, and DLQ count
Acceptance Criteria
All SorobanService calls go through the BullMQ queue (zero direct synchronous calls from controllers)
Exponential backoff is implemented with configurable base delay and max delay
Dead letter queue captures all permanently failed jobs with full error context
Idempotency key prevents duplicate submissions (tested with concurrent duplicate job submissions)
Admin status endpoint is protected by the admin permission and returns accurate queue metrics
Description
Blockchain transactions can fail due to network issues, sequence number conflicts, or Stellar network congestion. Direct fire-and-forget calls from NestJS to Soroban are not reliable enough for a healthcare application. We need a robust transaction queue with retry logic and dead letter handling.
Requirements
All Soroban contract calls must go through a BullMQ queue (soroban-tx-queue) instead of being called synchronously
Each job includes: contractMethod, args, idempotencyKey, maxRetries (default: 5)
Implement exponential backoff with jitter for retries
If a job exceeds maxRetries, move it to a dead letter queue (soroban-dlq) and emit an alert to admins
The idempotencyKey prevents duplicate on-chain submissions (checked against a Redis set before submission)
Expose a GET /blockchain/queue/status admin endpoint showing queue depth, failed jobs, and DLQ count
Acceptance Criteria
All SorobanService calls go through the BullMQ queue (zero direct synchronous calls from controllers)
Exponential backoff is implemented with configurable base delay and max delay
Dead letter queue captures all permanently failed jobs with full error context
Idempotency key prevents duplicate submissions (tested with concurrent duplicate job submissions)
Admin status endpoint is protected by the admin permission and returns accurate queue metrics