# fix(logs): leave update markers out of the session-loss 401 streak #75

Queued: the loop will work on this version of the issue.

loop:queued cid=bafyreigy2kobhmx3svoebcgskbtlzmlbyc24ppvmojstkj7irtgaw5bxry

Working on this, attempt 1.

loop:claim run=contribute-20261028-164922-3myulrzgamw22 branch=loop/3myulrzgamw22 attempt=1

The session needs an answer from the owner.

fix(logs): leave update markers out of the session-loss 401 streak

I stopped before changing anything. The issue fixes code that only exists on the #38 branch (loop/3my33bvptg222), but this run's branch, loop/3myulrzgamw22, starts from main (acb8f87). main has no deliveryLogs.kind column and no lib/automations/update-log.ts, so on this branch there is no marker to filter out and no marker to write in the test.

What I checked #

• rg -n kind lib/db/schema.ts on this branch: delivery_logs has no kind column. rg automation-updated finds nothing.
• git branch -a --contains 40136b2: only origin/loop/3my33bvptg222 has it. git log main..origin/loop/3my33bvptg222 lists 40136b2, 6e2226e and 94e2a89, none of which are on main.
• git merge-tree main origin/loop/3my33bvptg222: the #38 branch no longer merges cleanly with main. It conflicts in app/islands/DeliveryLog.tsx, app/routes/api/automations/[rkey].ts, app/routes/api/automations/[rkey]/logs.ts, app/routes/u/[handle]/[rkey]/logs.tsx and possibly more. It also adds migration 0003_known_princess_powerful.sql.

I can't switch to the #38 branch. To do this issue here I would have to merge that whole branch into this one and resolve its conflicts with main. That pulls all of #38 into this PR, which is outside this issue's scope, so I didn't do it.

What the owner needs to decide #

Which of these should I do?

1. Run this as a fix round on the #38 branch (loop/3my33bvptg222). This is the most direct option, and that branch needs a fix round for its conflicts with main anyway.
2. Merge #38 into main first, then re-run this issue on a fresh branch from main.
3. Let this branch merge origin/loop/3my33bvptg222, resolve its conflicts with main, and add the fix on top. This PR would then carry all of #38.

The change, once kind exists (from reading the #38 branch at 94e2a89) #

• lib/jetstream/session-loss.ts, disableForSessionLoss: add isNull(deliveryLogs.kind) to the where, next to eq(deliveryLogs.dryRun, false), and update the doc comment so it says the streak counts delivery rows only.
• lib/jetstream/session-loss.test.ts: insert 4 non-dry-run 401 rows, then one kind: "automation-updated" row (statusCode: null), then one more 401. Check that disableForSessionLoss returns true and the automation is inactive with disabledReason = "session_lost".
• On that branch, from(deliveryLogs) has 10 readers outside tests. Each needs a kind filter or a comment saying why it has none:
  • activity-summary.ts: 2 readers, already filtered since 94e2a89, to confirm.
  • admin-logs-query.ts: lists every row, so it gets a comment.
  • rate-limit.ts: already excludes markers through countsTowardRateLimit = false, so it gets a comment.
  • run-steps.ts: 3 readers, check each.
  • session-loss.ts: gets the filter above.
  • scripts/migrate-automations-to-steps.ts: 2 readers. This file matches the scripts/** ownerOnly glob only if the glob is root-anchored. It is under lib/scripts/, so it is editable.

Acceptance criteria #

• disableForSessionLoss filters isNull(deliveryLogs.kind). Blocked: the column is not on this branch.
• A test: 4 × 401, then a marker, then 401 still disables at threshold 5. Blocked: there are no markers on this branch.
• grep -rn "from(deliveryLogs)" shows that every reader either filters by kind or has a comment saying why it doesn't. Blocked: the same reason.

loop:awaiting-owner run=contribute-20261028-164922-3myulrzgamw22 why=needs-info