Resilience: hbf-media-manager
Error handling and retry patterns for this service. Platform-wide patterns:
docs/architecture/resilience.md
HTTP Retry
- Library: got (v11.8.5)
- Attempts: 0 (no retry configured)
- Backoff: None
- On failure: HTTPError thrown and logged at WARN
Queue Retry
Not applicable. No queue consumers in this service.
Timeouts
| Call | Timeout | Configured in |
|---|---|---|
| got HTTP calls | None (no explicit timeout) | got client |
| S3 operations | None (no explicit timeout) | AWS SDK |
| TypeORM / MySQL | Default MySQL connection timeout | TypeORM config |
| CoreClientService.getUserMe | None (no explicit timeout) | CoreClientService |
Circuit Breakers
None implemented.
Fallback Strategy
| Failure scenario | Behaviour | User impact |
|---|---|---|
| S3 upload fails | SaveToS3Exception thrown (HTTP 502) | Media upload fails with 502 |
| S3 delete fails | DeleteFromS3Exception thrown (HTTP 502) | Media deletion fails with 502 |
| Audit log creation fails | CreateAuditLogException thrown (HTTP 500), but caught and logged without stopping the media operation | Media operation succeeds, audit trail has gap |
| hbf-core API call fails | Error propagated | Dependent operation fails |
Health Check
- Endpoint: GET /health
- Response: 200 with empty body
- Checks: None (does not verify DB, S3, or hbf-core connectivity)
Known Gaps
- No retry on S3 operations (upload, delete)
- No retry or timeout on hbf-core API calls (CoreClientService.getUserMe)
- No timeout on got HTTP client calls
- Health endpoint returns 200 unconditionally without checking downstream dependencies (DB, S3, hbf-core)