Backend renamed a field. I re-recorded:
bun run sdods har record -p demo-shop -e staging -t @har:postsThe scenario passes now, but the file grew instead of being replaced, and the old response with the old field name is still sitting in there. I would rather not ship a recording that contains a payload the service can no longer produce. Is there a prune step I am missing?
Accepted answer
No prune step, and the two layers behave differently here, which is the part that confuses people.
The API recorder is append-or-refresh. For each request it computes the lookup key, and if an entry with that key already exists it replaces it, otherwise it appends. Nothing is ever removed, so an entry whose key no longer occurs stays in the file forever.
The browser recorder does not have that problem, because Playwright rewrites the file from the session rather than merging into it.
So for an API recording, delete first:
rm projects/demo-shop/har/staging/posts.api.har
bun run sdods har record -p demo-shop -e staging -t @har:postsLeave the sidecar alone, it gets merged and updated in place.
To be precise about why it grew rather than refreshed: the key includes a hash of the request body. If the backend change also changed what you send, the new request hashes differently, misses the existing entry and appends a second one. Same URL, same method, two entries, only one of which anything will ever ask for again.
That is also why an occasional delete-and-record is worth doing even when nothing broke.
Process suggestion rather than a mechanism: re-record in the same pull request that changes the API, not afterwards. Then the recording diff and the code diff are reviewed together and somebody notices when the payload changed in a way nobody intended.
The recorded column of sdods har list gives you the age of each one, which is a decent thing to glance at before a release.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question