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.
Have a different question? Ask it.