Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Long flight, and separately we are being asked to prove the suite runs on an air-gapped runner. Same problem twice, so I would like to get it right once.
Everything is tagged @har:<something> and the recordings are committed. If I just pull the cable, do the scenarios replay, or do they quietly go looking for the network for anything that was not captured?
Accepted answer
They go looking. Replay on its own is permissive: anything the recording does not answer falls through to the real network, which is fine on your desk and useless on a plane.
This is the whole recipe:
bun run sdods run -p demo-shop -e staging --har-replay --strict -t @smoke--strict alongside --har-replay turns the fall-through into an abort and sets offline mode for the run, so every request that is not in a recording fails loudly instead of leaving. That is the difference between "probably offline" and "provably offline": a missing entry is now a red scenario with a message naming the request.
Do a strict run once while you still have network. Everything you missed at record time shows up in that run and nowhere else.
That is the same command we put in the air-gapped job, so a couple of notes from running it in anger.
Offline mode blocks everything, not just the application. Analytics, fonts from a CDN, an error reporter — if the page asks for it and the recording does not answer it, it aborts. That is the point, but the first strict run after enabling it will be red for reasons that have nothing to do with your test.
A scenario without a @har tag in an offline run gets blocked wholesale and warned about:
SDODS_OFFLINE=1 but the scenario has no @har tag: all network requests are blocked.So restrict the offline job by tag, or make sure the suite it runs is fully recorded.
The thing that got us on an actual flight: authentication.
Cached login state lives under projects/<slug>/.auth/<env>/ and gets refreshed automatically when it expires. Refreshing means logging in, which means network. The demo targets public sandboxes whose session cookies live about ten minutes, so a cache captured in the departure lounge is stale before the seatbelt sign goes off, and offline it cannot be renewed.
Capture before you take off:
bun run sdods auth capture -p demo-shop -e staging --allOr record the login traffic into the HAR as well, so there is nothing to renew.
Late addition for anyone verifying this rather than trusting it: strict replay announces itself per scenario. You will not see it at the default log level though — it is emitted at step level, which sits above info, so you have to ask for it:
SDODS_LOG_LEVEL=step bun run sdods run -p demo-shop -e staging --har-replay --strict -t @smoke2025-11-20 08:41:07 [STEP] [har] ▶ HAR replay (strict): /srv/ci/projects/demo-shop/har/staging/products.harOne line per routed scenario. That was how we found two scenarios in the offline job that had lost their tag in a rename and had been going to the network the whole time.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.