Skip to main content
← Back to list
01Issue
BugShippedSwamp CLIPublicTeam
Assigneesstack72

Relationships

#1984 readResource returns stale cursor on serve scheduled workflow runs

Opened by magistr · 9/3/2026· Shipped 9/3/2026

Summary

readResource inside a serve-scheduled workflow step returns a stale cursor despite the filesystem latest marker pointing to the correct version. This causes the anilist-activity-hourly notifier to re-send the same activities every hour.

Diagnostic evidence

Added console.error after readResource in the anilist extension. On a serve in-container method run:

[CURSOR-DIAG] stored=object keys=["users"] users=18 magistrId=1148064558
[CURSOR-DIAG] lookbackCutoff=1788445875 (2026-09-03T14:31:15.000Z) lookbackMinutes=60
[CURSOR-DIAG] Magistr: userFloor=1788361865 (2026-09-02T15:11:05.000Z) lastSeenId=1148064558

The filesystem latest marker says v618, and v618/raw on disk contains magistrId=1148742247 (correct). But readResource returned 1148064558 (matching a version from Sep 2 ~19:00 that was GC'd from disk).

Root cause hypothesis

The step-level FileSystemUnifiedDataRepository (created in buildDeps) has no hydrateFile callback. On serve with the MongoDB datastore + lazy hydration, version directories exist as metadata stubs (metadata.yaml present, raw content absent). getContent reads latest -> 618 -> tries Deno.readFile(v618/raw) -> NotFound -> hydrateFile is undefined -> returns null. Then it appears to fall back to some other resolution path that returns a much older cursor version.

Key details:

  • Serve: v20260903.004401.0-sha.f2eefb58
  • MongoDB datastore: @magistr/swamp-mongodb-datastore v0.3.0
  • MongoDB paths collection has ZERO entries for activity-cursor (push not syncing cursor)
  • 618 version dirs exist inside container, only v90-99 visible on host mount
  • The workflow YAML comment confirms Lab #974 was never fixed: "the cursor resource is empty every run"

Impact

Every hourly run re-sends the same ~7 activities to the Telegram group. Schedule disabled 2026-09-03. Diagnostic logging deployed to serve.

Steps to reproduce

  1. Configure a model with a resource spec (lifetime: infinite, garbageCollection: 5)
  2. Run a workflow step on serve that writes the resource via writeResource
  3. Run the same workflow step again — readResource returns stale/null instead of the previous run's write
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 7 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

9/3/2026, 7:03:21 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack729/3/2026, 5:25:49 PM
Editable. Press Enter to edit.

stack72 commented 9/3/2026, 7:03:30 PM

Thanks @magistr for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.