Resilience: hbf-reports
Error handling and retry patterns for this service. Platform-wide patterns:
docs/architecture/resilience.md
HTTP Retry
- Library: got (http-client.service.ts) + hbf-core-api (inherited)
- Attempts: got: 0 (retry not enabled); hbf-core-api: 3 (inherited, network errors only)
- Backoff: None for got; exponential for hbf-core-api (inherited)
- On failure: got errors logged at WARN and re-thrown; hbf-core-api retries then throws
Queue Retry
Not applicable. No queue consumers in this service.
Timeouts
| Call | Timeout | Configured in |
|---|---|---|
| got HTTP calls | None (no explicit timeout) | http-client.service.ts |
| hbf-core-api calls | None (no explicit timeout) | hbf-core-api client |
Circuit Breakers
None implemented.
Fallback Strategy
| Failure scenario | Behaviour | User impact |
|---|---|---|
| Individual API call in report generation fails | Error caught and logged, execution continues | Report generated with partial/missing data |
| PDF generation fails | Error caught and logged | Report may silently fail to produce output |
| http-client.service.ts call fails | Error logged at WARN, re-thrown to caller | Caller receives error |
Known Gaps
- http-client.service.ts uses got without retry (contrast with hbf-client-integrations which configures got with retry)
- No timeout on got or hbf-core-api HTTP calls
- Silent failures possible in report generation pipeline: individual data-fetch failures are caught so the report continues with incomplete data, with no signal to the user
- No /health endpoint for liveness or readiness probes