⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this
work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that
satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
partially-done does NOT resolve this issue and will be closed.
Context
src/orb/relay.ts:384-405's enqueueConfigPushRelay, fanned out at src/api/routes.ts:1989 via await Promise.all(installationIds.map((installationId) => enqueueConfigPushRelay(c.env, installationId, payload))). Up to 500 installationIds (per configPushSchema) are processed with two sequential un-guarded DB writes each, inside a bare Promise.all, with no route-level try/catch around it. If one write throws for one installation, the whole request throws -- no recordAuditEvent call, no partial-success report. This is the exact class of bug already fixed elsewhere in the same subsystem: pollPendingAprRepoTransfers (src/orb/apr-repo-transfer.ts:292-319, tested by "continues processing later transfers when one probe rejects") and finalizeRelayFailureRetryRow isolation (#8332/#8462) both isolate per-item failures so one bad row can't sink the batch.
Requirements
Isolate each enqueueConfigPushRelay call (e.g. Promise.allSettled plus a per-installation try/catch/log) so one failing target doesn't drop the audit event / response for the other ~499, matching pollPendingAprRepoTransfers's existing isolation pattern.
Deliverables
All of the above Deliverables are required in the same PR unless the deliverable text itself states otherwise.
Test Coverage Requirements
src/** -- 99%+ patch coverage, branch-counted, on the new isolation path.
Expected Outcome
One failing installation in a config-push fan-out no longer drops the audit event or response for the other ~499 targets in the batch.
Links & Resources
src/orb/relay.ts:384-405
src/api/routes.ts:1989
src/orb/apr-repo-transfer.ts:292-319
test/unit/routes-config-push.test.ts
Context
src/orb/relay.ts:384-405'senqueueConfigPushRelay, fanned out atsrc/api/routes.ts:1989viaawait Promise.all(installationIds.map((installationId) => enqueueConfigPushRelay(c.env, installationId, payload))). Up to 500installationIds(perconfigPushSchema) are processed with two sequential un-guarded DB writes each, inside a barePromise.all, with no route-level try/catch around it. If one write throws for one installation, the whole request throws -- norecordAuditEventcall, no partial-success report. This is the exact class of bug already fixed elsewhere in the same subsystem:pollPendingAprRepoTransfers(src/orb/apr-repo-transfer.ts:292-319, tested by "continues processing later transfers when one probe rejects") andfinalizeRelayFailureRetryRowisolation (#8332/#8462) both isolate per-item failures so one bad row can't sink the batch.Requirements
Isolate each
enqueueConfigPushRelaycall (e.g.Promise.allSettledplus a per-installation try/catch/log) so one failing target doesn't drop the audit event / response for the other ~499, matchingpollPendingAprRepoTransfers's existing isolation pattern.Deliverables
enqueueConfigPushRelay's fan-out atsrc/api/routes.ts:1989isolates per-installation failures (e.g. viaPromise.allSettled) instead of a barePromise.allrecordAuditEvent(or equivalent) rather than silently droppedtest/unit/routes-config-push.test.tsfor a partial-failure fan-out, asserting the other installations still succeed and the response reports the partial failureAll of the above Deliverables are required in the same PR unless the deliverable text itself states otherwise.
Test Coverage Requirements
src/**-- 99%+ patch coverage, branch-counted, on the new isolation path.Expected Outcome
One failing installation in a config-push fan-out no longer drops the audit event or response for the other ~499 targets in the batch.
Links & Resources
src/orb/relay.ts:384-405src/api/routes.ts:1989src/orb/apr-repo-transfer.ts:292-319test/unit/routes-config-push.test.ts