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.
Four scenarios share @har:cart. I recorded them together to save time:
SDODS_HAR_MODE=update bun run sdods run -p demo-shop -e staging -l ui -b chromium -t @har:cart -w 4The run was green and the file exists, but on replay two of the four scenarios abort on requests that definitely happened during recording. Re-running the recording gives me a different two. Nothing in the output complains.
Accepted answer
Four workers sharing one recording name means four contexts writing the same file, each one flushing what it saw when it closed. Last close wins and the rest is gone — which matches your "different two each time".
The runner already guards against this, but only when the mode comes from the flags. Passing --har-update clamps the run to a single worker and warns:
Recording HAR fixtures runs with a single worker so shared files keep every request.You set SDODS_HAR_MODE in the environment instead. That variable is read further down, when each worker resolves its own config, so the command never knew it was a recording run and never clamped anything. Hence no warning.
Use the flag, or the wrapper that sets it for you:
bun run sdods har record -p demo-shop -e staging -t @har:cartRecording is a one-off authoring step, so the serial run costs you a minute and nothing else.
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.