fix(agent): log the real fetch/submit failure reason (diagnose #1225) #180

2026-07-01T12:37:41-04:00

bvandeusen commented

2026-07-01 12:37:41 -04:00

"curator unreachable" was logged for every transient error, hiding whether a single file's transfer stalled (ReadTimeout — curator up, stream slow) vs curator being down (ConnectTimeout/ConnectionError) vs erroring (HTTP 5xx). Those need different fixes and we've been diagnosing the download slowness blind.

Adds _transient_reason(exc) and rewrites both transient logs:

downloader → fetch failed job <id> (image <id>, ReadTimeout) — released, backing off
consumer → submit failed job <id> (<reason>) — released, re-lease later

Now the logs name the actual failure + image, so we can tell a slow/stalled transfer apart from an unreachable curator. Build marker 2026-07-01.5. CI green (run 1831). Refs #1225.

🤖 Generated with Claude Code

"curator unreachable" was logged for every transient error, hiding whether a single file's transfer stalled (ReadTimeout — curator up, stream slow) vs curator being down (ConnectTimeout/ConnectionError) vs erroring (HTTP 5xx). Those need different fixes and we've been diagnosing the download slowness blind. Adds `_transient_reason(exc)` and rewrites both transient logs: - downloader → `fetch failed job <id> (image <id>, ReadTimeout) — released, backing off` - consumer → `submit failed job <id> (<reason>) — released, re-lease later` Now the logs name the actual failure + image, so we can tell a slow/stalled transfer apart from an unreachable curator. Build marker `2026-07-01.5`. CI green (run 1831). Refs #1225. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bvandeusen added 1 commit 2026-07-01 12:37:41 -04:00

fix(agent): log the REAL fetch/submit failure reason, not "curator unreachable"

CI / lint (push) Successful in 3s

Details

CI / frontend-build (push) Successful in 19s

Details

CI / backend-lint-and-test (push) Successful in 27s

Details

CI / integration (push) Successful in 3m26s

Details

aa0605585b

"curator unreachable" was printed for every transient error, hiding whether a
single file's transfer stalled (ReadTimeout — curator is up, that stream is slow)
or curator itself is down (ConnectTimeout/ConnectionError) or errored (HTTP 5xx).
Those need completely different fixes, and we've been diagnosing the download
slowness blind.

Add _transient_reason(exc) → a specific label (HTTP <code>, else the exception
class: ReadTimeout / ConnectTimeout / ConnectionError / …) and use it in both
transient paths:
- downloader: "fetch failed job <id> (image <id>, ReadTimeout) — released, backing off"
- consumer:   "submit failed job <id> (<reason>) — released, re-lease later"

Now the logs say which failure it actually is (and which image), so we can tell a
slow/stalled transfer apart from an unreachable curator. Build marker 2026-07-01.5.
Refs issue #1225.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ttrj5P7upUTueSfoJcxEqa

bvandeusen merged commit 2a820d0848 into main

2026-07-01 12:37:45 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bvandeusen/FabledCurator#180