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

Relationships

#1830 SWAMP_SERVER_URL is ignored for routing: commands silently read the local repository

Opened by khudgins · 8/26/2026· Shipped 8/26/2026

Corrected 2026-08-26. The original report claimed swamp serve kept two disconnected data stores. That was wrong, and it was my own misdiagnosis. The real fault is below, and it is what produced every symptom I described.

Summary

SWAMP_SERVER_URL does not route a command to the server. It is read when resolving credentials, but not when choosing where the command runs, so commands fall back to the local repository and return local data as though it came from the server. No warning, no error.

The result is worse than a failure: plausible, well-formed, wrong data.

Reproduce

With SWAMP_SERVER_URL and SWAMP_SERVER_TOKEN both exported, from inside any local swamp repository:

$ swamp data list <model> --json                              # env var only
  7 records

$ swamp data list <model> --server "$SWAMP_SERVER_URL" --json # identical URL
  123 records

Same command, same directory, same URL. The first reads the local repository; the second reads the server.

The proof that no remote call is attempted in the first case: run it from a directory that is not a swamp repository.

$ cd /tmp && swamp data list <model> --json
  {"error": "Not a swamp repository: /tmp. To initialize a new repository..."}

If the env var were routing, that command would not need a local repository at all.

Observed on data get, data list, run history and workflow search.

Why this is costly

The two stores are both legitimate and both plausible, so nothing looks broken. In my case a CI driver read the verdicts of pipeline runs and got a coherent set of records that were four days stale, because they were its own laptop's copies. The gates that consume those verdicts silently stopped meaning anything - a verdict is either present and green or absent, and absent reads as "not finished yet", never as "you asked the wrong machine".

I spent several hours ruling out catalog staleness, WAL visibility, repo directory, model id, startup caching, binary version skew, file layout and permissions before noticing the real difference was a flag I had stopped passing.

Suggested fixes, in order of preference

  1. Honour SWAMP_SERVER_URL for routing, matching --server. This is what the name implies and what the credential path already assumes.
  2. If it is deliberately credential-only, rename it (SWAMP_SERVER_CREDENTIAL_URL) and say so in --help, because the current name reads as routing.
  3. At minimum, when SWAMP_SERVER_URL is set and a command runs locally anyway, log a warning naming which repository answered. A silent fallback between two real data sources is the failure mode worth removing.

Version

swamp 20260812.013400.0-sha.278864d1, macOS client, Linux orchestrator.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 6 MOREPR_LINKED+ 2 MORESESSION_SUMMARIZED

Shipped

8/26/2026, 8:06:12 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/26/2026, 7:13:51 PM
Editable. Press Enter to edit.

khudgins commented 8/26/2026, 7:20:17 AM

Correction from the reporter: the original title and body claimed swamp serve maintained two disconnected data stores. That was a misdiagnosis and the issue has been edited in place.

The evidence I read as "the server's view" was my own client's local repository, because SWAMP_SERVER_URL does not route. Every symptom follows from that single fact, including the one I could not explain: a record I believed I had written through the socket "survived a restart" with no trace on the orchestrator, because it had never been on the orchestrator at all.

What actually held up from the original investigation, and is still true:

  • the catalog is not stale, WAL is visible to readers, and the on-disk layout is consistent
  • workflow run search --status running needs only read on workflow:, while run history --active requires admin on model: — a real asymmetry for anyone running a non-admin client

Apologies for the noise. The corrected report is a smaller bug but a sharper one.

stack72 commented 8/26/2026, 8:06:15 PM

Thanks @khudgins 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.