|
| 1 | +# Error & Support Playbook |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +Every API error response includes a `requestId` (correlation ID) that links the |
| 6 | +user-facing error to a specific backend log entry. Support agents should always |
| 7 | +ask users for this reference before escalating. |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +## 1. Finding a Correlation ID |
| 12 | + |
| 13 | +### From the UI |
| 14 | +Users see the reference in error toasts and inline error messages: |
| 15 | +> "Something went wrong. (Ref: `req_abc123`)" |
| 16 | +
|
| 17 | +### From the API response body |
| 18 | +```json |
| 19 | +{ |
| 20 | + "statusCode": 500, |
| 21 | + "requestId": "req_abc123", |
| 22 | + "error": "SERVER_ERROR", |
| 23 | + "message": "Internal server error" |
| 24 | +} |
| 25 | +``` |
| 26 | + |
| 27 | +### From response headers |
| 28 | +``` |
| 29 | +x-request-id: req_abc123 |
| 30 | +``` |
| 31 | + |
| 32 | +--- |
| 33 | + |
| 34 | +## 2. Log Lookup |
| 35 | + |
| 36 | +### NestJS backend (structured JSON logs) |
| 37 | +```bash |
| 38 | +# Grep by requestId in production logs |
| 39 | +grep '"requestId":"req_abc123"' /var/log/app/app.log |
| 40 | + |
| 41 | +# Or with jq |
| 42 | +cat /var/log/app/app.log | jq 'select(.requestId == "req_abc123")' |
| 43 | +``` |
| 44 | + |
| 45 | +### Grafana / Loki |
| 46 | +```logql |
| 47 | +{app="niffyinsur-backend"} |= "req_abc123" |
| 48 | +``` |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +## 3. Error Code Reference |
| 53 | + |
| 54 | +| Code | HTTP | Meaning | Action | |
| 55 | +|------|------|---------|--------| |
| 56 | +| `UNAUTHORIZED` | 401 | Session expired | Ask user to reconnect wallet | |
| 57 | +| `FORBIDDEN` | 403 | Insufficient role | Verify user permissions | |
| 58 | +| `RATE_LIMIT_EXCEEDED` | 429 | Too many requests | Wait and retry; check for abuse | |
| 59 | +| `TRANSACTION_FAILED` | 400 | Stellar tx rejected | Check Stellar explorer with tx hash | |
| 60 | +| `SIGNATURE_INVALID` | 400 | Bad wallet signature | Ask user to retry signing | |
| 61 | +| `INSUFFICIENT_BALANCE` | 400 | Not enough XLM/token | User needs to fund wallet | |
| 62 | +| `LEDGER_CLOSED` | 400 | Tx missed ledger window | Resubmit transaction | |
| 63 | +| `SOROBAN_RPC_ERROR` | 502 | RPC node issue | Check RPC node health; retry | |
| 64 | +| `OPEN_CLAIM_EXISTS` | 409 | Duplicate claim attempt | Explain existing open claim | |
| 65 | +| `SERVER_ERROR` | 500 | Unhandled exception | Escalate with requestId | |
| 66 | + |
| 67 | +--- |
| 68 | + |
| 69 | +## 4. Stellar Transaction Debugging |
| 70 | + |
| 71 | +1. Extract `transactionHash` from the error details or user report. |
| 72 | +2. Look up on Stellar Expert: |
| 73 | + - Testnet: `https://stellar.expert/explorer/testnet/tx/<hash>` |
| 74 | + - Mainnet: `https://stellar.expert/explorer/public/tx/<hash>` |
| 75 | +3. Check the result code (e.g. `tx_failed`, `op_underfunded`). |
| 76 | +4. Map to the error code table above. |
| 77 | + |
| 78 | +> **Security**: Never ask users to share private keys, seed phrases, or signed |
| 79 | +> XDR outside of a verified secure developer tool. These are never required for |
| 80 | +> support escalation. |
| 81 | +
|
| 82 | +--- |
| 83 | + |
| 84 | +## 5. Escalation Path |
| 85 | + |
| 86 | +1. **Tier 1** — User self-service: retry button in UI, reconnect wallet. |
| 87 | +2. **Tier 2** — Support agent: collect `requestId`, look up logs, check Stellar explorer. |
| 88 | +3. **Tier 3** — Engineering: provide `requestId` + full log context + Stellar tx hash. |
| 89 | + |
| 90 | +--- |
| 91 | + |
| 92 | +## 6. PII Policy for Error Events |
| 93 | + |
| 94 | +Anonymized error events forwarded to observability tools **must not** include: |
| 95 | +- Wallet addresses (truncate to first 6 + last 4 chars if needed for grouping) |
| 96 | +- Email addresses |
| 97 | +- IP addresses (hash or omit) |
| 98 | +- Private keys, seeds, or signed XDR (never, under any circumstances) |
| 99 | + |
| 100 | +See `backend/src/maintenance/privacy.service.ts` for the data-scrubbing implementation. |
0 commit comments