This repository was archived by the owner on Jun 8, 2026. It is now read-only.
Commit 8212516
FEA-1461: PR #258 review fixes (P1 relay flap + backfill starvation + test helper dedup)
Codex P1 (relay-flap dead-letter):
- cloud-socket.sendAgentSessions returns RateLimited for BOTH server-side
payload throttling AND local transport unavailability (!isRelayReady()
or socket disconnected after the batch was prepared). The previous code
treated both as session-payload problems and would dead-letter perfectly
good sessions after 5 disconnects. handleBatchAck now re-checks
isRelayReady() at ack time; when the relay is down, the rate-limit
counter is NOT advanced. The session still gets a backoff (so we don't
hot-loop), but its dead-letter trajectory restarts the moment the relay
recovers. Log line distinguishes "server payload throttle" vs
"transport unavailable" so operators can tell them apart.
thadeusb (backfill starvation):
- Restructure syncOnce candidate selection: if the incremental branch
picks zero ready candidates (every session in rate-limit backoff), fall
through to backfill instead of hitting the early-return. Before this
fix the incremental queue being non-empty-but-all-backed-off blocked
backfill for the entire backoff window. Hidden today because
RATE_LIMIT_BACKOFF_MS == MIN_INCREMENTAL_SYNC_INTERVAL_MS (both 30s),
but a future backoff tune past 30s would expose it.
thadeusb (test helper duplication):
- Extract createServiceTestDatabase + flushAgentSessionSync +
insertSessionRow into new test/helpers/agent-session-sync-test-utils.ts
so future agent-monitor schema migrations force both test suites to
update in lockstep. CLAUDE.md flags this exact `tests|duplication`
learned-mistake.
New tests:
- "rate_limited that races with a relay drop does NOT advance the
dead-letter counter" — simulates the race by having sendBatch flip
relayReadyValue=false right before returning RateLimited. Drives 2x
the threshold under flap conditions and asserts the counter stays at
0 (proved indirectly: switching back to healthy-relay rate_limiteds
then takes exactly MAX_CONSECUTIVE_RATE_LIMITED attempts to dead-letter,
which only holds if the flap counter wasn't advanced).
- "backfill is not starved when every incremental candidate is in
rate-limit backoff" — sessions in both queues, incremental in backoff,
asserts backfill still flows.
Bump desktop version 0.15.99 → 0.15.101 (0.15.100 reserved for FEA-1444).
Testing:
- pnpm -C apps/desktop typecheck: clean
- pnpm -C apps/desktop lint: clean
- New rate-limit tests: 6/6 pass (was 4 before this commit)
- Full suite: 1833 + 104 = 1937/1937 pass, 0 fail
- Independent code review on the original FEA-1461 commit caught a Medium
+ Low; thadeusb's peer review on the PR caught this round of three
more findings (P1 relay-flap + Medium backfill starvation + Low test
dedup). All addressed in this commit.
Risks:
- The flap detection is heuristic (re-reads isRelayReady at ack time). A
relay that goes down between sendBatch returning and handleBatchAck
running's isRelayReady check would not be detected — but that window
is microseconds, and the worst case (counter advances by 1) is far
better than the prior worst case (dead-letter after 5 flaps).
- The fallthrough to backfill in syncOnce changes priority slightly: when
incremental is empty-but-blocked, backfill now runs on the same tick
instead of being deferred. Increases backfill throughput by up to one
tick per incremental-backoff window. Net positive for cloud sync.1 parent e8a13cd commit 8212516
5 files changed
Lines changed: 402 additions & 220 deletions
File tree
- apps/desktop
- src/main
- test
- helpers
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1 | 1 | | |
2 | 2 | | |
3 | | - | |
| 3 | + | |
4 | 4 | | |
5 | 5 | | |
6 | 6 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
296 | 296 | | |
297 | 297 | | |
298 | 298 | | |
| 299 | + | |
| 300 | + | |
| 301 | + | |
| 302 | + | |
| 303 | + | |
299 | 304 | | |
300 | 305 | | |
301 | 306 | | |
302 | 307 | | |
303 | 308 | | |
304 | | - | |
305 | | - | |
306 | | - | |
307 | | - | |
308 | 309 | | |
309 | 310 | | |
310 | 311 | | |
311 | 312 | | |
312 | 313 | | |
313 | | - | |
314 | | - | |
315 | | - | |
316 | | - | |
317 | | - | |
318 | 314 | | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
319 | 321 | | |
320 | 322 | | |
321 | | - | |
322 | | - | |
323 | | - | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
324 | 326 | | |
325 | 327 | | |
326 | 328 | | |
327 | 329 | | |
| 330 | + | |
| 331 | + | |
| 332 | + | |
| 333 | + | |
328 | 334 | | |
329 | 335 | | |
330 | 336 | | |
| |||
644 | 650 | | |
645 | 651 | | |
646 | 652 | | |
| 653 | + | |
| 654 | + | |
| 655 | + | |
| 656 | + | |
| 657 | + | |
| 658 | + | |
| 659 | + | |
| 660 | + | |
| 661 | + | |
| 662 | + | |
647 | 663 | | |
648 | 664 | | |
649 | 665 | | |
650 | 666 | | |
651 | | - | |
652 | | - | |
| 667 | + | |
| 668 | + | |
| 669 | + | |
653 | 670 | | |
654 | 671 | | |
655 | 672 | | |
| |||
658 | 675 | | |
659 | 676 | | |
660 | 677 | | |
661 | | - | |
| 678 | + | |
| 679 | + | |
| 680 | + | |
662 | 681 | | |
663 | 682 | | |
664 | 683 | | |
| |||
677 | 696 | | |
678 | 697 | | |
679 | 698 | | |
680 | | - | |
| 699 | + | |
| 700 | + | |
681 | 701 | | |
682 | 702 | | |
683 | 703 | | |
| |||
0 commit comments