LogisticsRnD: 5 logged issues — root causes and fixes

Chief log-fix session c0e8be4273 · 2026-10-26 · branch chief/c0e8be4273 · not merged, not deployed (Chief's test gate and the owner decide)

In one line: the five log lines came from three real problems. Every sync downloaded old mail attachments again, so a Composio outage failed the sync. A folder dropped on an analysis was sent as a "file". Deleting an analysis made the page re-read what it had just deleted. All three were reproduced and fixed, each with a test that fails before the fix and passes after.

Per issue

fixed1 · sync.run_failed (5×) & 2 · health.mail_sync (1×)

What happened
Between 11:24 and 12:15 UTC, Composio's attachment download (GMAIL_GET_ATTACHMENT) answered "HTTP 401: Admin token missing or invalid" from its own file store. Five syncs failed, and the health check reported the latest sync as broken. It stopped on its own after 12:15.
Root cause
The six attachments in those failures had been saved and indexed hours earlier. Each sync re-reads the last two days of mail and downloaded them again: the "already saved" key used Gmail's attachment id, and Gmail issues a new one on every fetch. One workspace had 1,070 such keys for 13 attachments; one file had been fetched 289 times.
Fix
  • The key is now Gmail's fixed MIME part id. Outlook ids were already stable.
  • When a new attachment really fails, the run error names the provider's reason.
  • Each failure is reported where it happened, as sync.attachment_failed: warn when the provider refuses, error when our code is at fault.
  • The run-level event then counts as the same issue, not a second bug.
Verified
  • New test sync-attachments: before the fix it failed with "downloaded again: 2 ≠ 1"; it passes after.
  • After the fix, a sync during a simulated outage finishes "done", and the health check reads "ok".

fixed3 · api.logistics.analyses.uploads (2×) "CMR+T1: accepted files are …"

What happened
Someone dropped a folder named "CMR+T1" on an analysis, twice, and both times it was refused. One minute later the T1 and CMR PDFs, apparently the folder's contents, were uploaded one by one.
Root cause
The browser hands a dropped folder over as a single pseudo-file named after the folder (no extension, 4096 bytes), and the drop zone posted it as a file.
Fix
  • Dropped folders are read and the files inside them are uploaded, subfolders included.
  • Files in the folder that are not an accepted type, such as Thumbs.db, are listed as "not uploaded" instead of being sent.
Verified
  • In real Chrome, with the original code, the same error as in production. With the fix, the files inside are uploaded (status 201).
  • New unit test dropped-files (3 cases).
Before: the dropped folder CMR+T1 is refused as a file
Before: the folder is sent as a file and refused, with a misleading "Resume" button.
After: the files inside the folder are uploaded
After: the files inside are uploaded, and Thumbs.db is listed as not uploaded (local test data).

fixedcause inferred4 · api.logistics.analyses.desk & 5 · api.logistics.analyses "Analysis not found."

What happened
One workspace got two 404s, 6 ms apart, for an open, finished analysis. Seven seconds later, the same workspace started a new analysis.
Root cause
Reproduced in Chrome. Delete opens a confirm dialog, and closing it refocuses the window. The page re-reads the analysis and its checklist on focus, so both reads went out right behind the DELETE and got 404. The person also saw "Analysis not found." flash.
Fix
  • Once a deletion is confirmed, the page stops reading the analysis and shows "Deleting the analysis…".
  • Deletions are now recorded as an info event (logistics.analysis_deleted).
Verified
  • A real-browser check (scripts/browser-use/checks/delete-analysis.py) failed before the fix with exactly the two 404s, and passed 3 out of 3 runs after it.
  • A unit test covers the deletion record.
Caveat
Deletions were not logged before this change, so it is not proven which analysis was deleted in production, or that it was deleted from this same tab rather than another one.

Before → After

AspectBeforeAfter
Attachment downloads per syncevery attachment in the 2-day window, every 10 minonly attachments not yet saved
Composio file-store outageevery sync fails; health warnssyncs finish unless a new attachment fails, and then the provider's reason is named
Dropping a folderrefused as a file "CMR+T1"its files are uploaded
Deleting an analysisDELETE + two 404 reads + error flashDELETE only, then the list

Not achieved / unknowns

Verification

Commits