- Shipped
- July 4, 2026 at 1:18 AM UTC
- Author
- Kamo
- Commit
- b361f0a
Adversarial review (2 lenses; 5 verifiers died on a session limit - adjudicated the 9 raw findings by hand, 6 real): - WRONG SECRET (confirmed by hash comparison): daemon's internal.auth.secret resolves to the public-chat value, but VOIP's /api/bulktext/send validates mlos-internal-auth - every steward SMS would have 403'd once numbers were configured (the record-only default masked it in E2E). StewardNotifier now binds the dedicated mlos.internal-auth-secret property; deployment mounts mlos-internal-auth; configmap maps INTERNAL_AUTH_SECRET. - new RestTemplate() had infinite timeouts - a hung VOIP call would wedge the durable's ONLY consumer thread inside an open CRDB tx with no error, stalling all steward fan-out until pod restart. Connect 3s / read 5s; a timeout now surfaces as ResourceAccessException -> RETRY -> DLQ as designed. - max-attempts silently capped by **************** raising the knob above the broker cap would lose events with NO dead letter. Effective cap = min(max-attempts, max-deliver), warn on clamp, configmap documents the coupling. - Permanent per-number 4xx (bad number / 422 no provider) now logged + SKIPPED (retrying can never succeed and re-spams earlier numbers each redelivery); 429 and 5xx still propagate to the RETRY path. - Boot-time subscribe failure no longer leaves the consumer silently dead: rebind retries every 30s (40 attempts) in the background. (The same pattern in the pre-existing timer-breach consumer is a follow-up.) - Tests: MlosTaskResolvedConsumerTest (incl. the occurredAt JSR-310 fixture on ITS mapper + the clamp), DEAD_LETTERED-must-ack on both consumers, StewardNotifier send contract (URL/header/body) + 4xx-skip + 5xx-propagate. 15/15.