docs: sync from backend 19f7eb9, frontend 60ee6fb — Task #10 AML screening

This commit is contained in:
Siavash Sameni
2026-05-28 20:35:38 +04:00
parent fd2aa71ef4
commit ddc0434819
34 changed files with 709 additions and 453 deletions

View File

@@ -13,7 +13,7 @@ Runbooks for the most likely production incidents, plus communication templates
| Sev | Meaning | Response time | Examples |
|-----|---------|---------------|----------|
| **Sev 1** | Site fully down or unable to process payments | 15 min | Backend container in crashloop; Mongo unreachable; SHKeeper API permanently failing |
| **Sev 1** | Site fully down or unable to process payments | 15 min | Backend container in crashloop; Mongo unreachable; Request Network API/webhooks failing |
| **Sev 2** | Major feature broken for a large share of users | 1 hour | Email sending broken; Redis disk full; chat undelivered |
| **Sev 3** | Minor / cosmetic issue, isolated user reports | next business day | Single failed webhook; one user can't upload PDF |
| **Sev 4** | No user impact, hygiene item | backlog | Backup older than 24h; disk > 80%; missed deploy |
@@ -133,35 +133,34 @@ The app gracefully degrades when Redis is unreachable for short windows — don'
---
### 3.4 SHKeeper API down (payments blocked)
### 3.4 Request Network API/webhook down (payments degraded)
**Symptoms.** Backend logs show repeated `SHKeeper request failed: ECONNREFUSED` or non-2xx responses from `$SHKEEPER_API_URL`. Buyers see "Payment unavailable" in checkout. Sev 1 — money is involved.
**Symptoms.** Backend logs show repeated Request Network API failures, webhook delivery failures, or payments stuck in pending/safety-pending. Buyers see "Payment unavailable" or a checkout that never confirms. Sev 1 — money is involved.
**Runbook.**
```bash
# 1. Confirm SHKeeper itself is reachable
curl -fsS -H "X-Shkeeper-Api-Key: $SHKEEPER_API_KEY" \
"$SHKEEPER_API_URL/api/v1/healthcheck"
# 1. Confirm Request Network API is reachable
curl -fsS -H "Authorization: Bearer $REQUEST_NETWORK_API_KEY" \
"$REQUEST_NETWORK_API_BASE_URL"
# 2. If 5xx from SHKeeper → it's their side
# 2. If 5xx from Request Network -> provider/API side
# - Check their status page / contact provider
# - Toggle a banner in the frontend warning buyers
# - Consider switching SHKEEPER_FORCE_PAYOUT_DEMO=true so QA still works
# (do NOT do this for real customer money)
# - Pause new checkout creation if confirmations cannot be reconciled
# 3. If our network can't reach it:
# - test from the host: curl from the host vs from inside the container
docker exec nickapp-backend curl -v "$SHKEEPER_API_URL"
docker exec nickapp-backend curl -v "$REQUEST_NETWORK_API_BASE_URL"
# - DNS / firewall changes?
# 4. While blocked, monitor stuck payments
docker exec nickapp-mongodb mongosh --eval \
"use marketplace; db.payments.find({status:'pending', createdAt:{\$lt: new Date(Date.now() - 30*60*1000)}}).count()"
# 5. Once SHKeeper is back, the app retries automatically. Verify the
# backlog drains. If a payment is stuck > 24h, manually verify against
# SHKeeper and use fix-transaction-hashes.js if needed.
# 5. Once Request Network/webhook delivery is back, replay or reconcile
# pending events. If a payment is stuck > 24h, manually verify the
# on-chain transfer, Transaction Safety Provider result, and ledger state.
```
**Always communicate.** Even short payment outages erode trust — post a status update.
@@ -422,7 +421,7 @@ Store postmortems alongside this vault — suggested path `/Users/mojtabaheidari
| Payments lead | <name> | <name> | DM |
| Infrastructure | <name> | <name> | DM |
| Product / customer comms | <name> | <name> | #customer-comms |
| SHKeeper provider contact | <email> | — | email |
| Request Network/provider contact | <email> | — | email |
| SMTP provider | <email> | — | email |
---