← All questions

GET replays fine, the POST in the same scenario misses on every run

bun run sdods har replay -p demo-shop -e staging -t @har:posts --strict

Error: HAR strict mode: no recorded entry for POST https://jsonplaceholder.typicode.com/posts 0736c37d8e28 in /home/tanvi/work/projects/demo-shop/har/staging/posts.api.har

3 answers

• Accepted answer

  It is a fingerprint of the request body. The API replayer does not scan entries looking for a match, it builds a key and does a map lookup, and the key is three parts:

  textCopy

  <METHOD> <normalised URL> <sha1 of the body, first 12 chars>

  A GET has no body, so its key is just method and URL and it will keep matching forever. Your POST has a body, so the third part moves whenever the body does — and the error is telling you the body you are sending now hashes to 0736c37d8e28, which is not what you recorded.

  The usual cause is a generated body. If the request is built from the factory, or carries a timestamp, a UUID or a random email, every run produces a new hash and the entry recorded yesterday can never be hit again.

  Make the body deterministic — a dataset row rather than a generated value — and then re-record. Grep the file for _sdods and you will see the recorded keys; that is what you need yours to equal.

  JOanswered by Jide Okonkwo

  Reply

• Before you blame the body, rule out the URL half, because it is normalised and not everything survives:

  • query parameters named _, t, ts, timestamp, nonce, cb or cache are dropped, so a cache-buster does not break matching
  • the remaining parameters are sorted, so parameter order does not matter
  • the host is lowercased and a trailing slash on the path is stripped

  Any other query parameter is part of the key. A page size or a filter that differs between the recording and the run gives you exactly this error.

  On the body side, object keys are sorted before hashing, so key order is not the culprit — only an actual value difference is.

  HWanswered by Hsu Wei-lin

  Reply

• Landing here from a UI scenario: none of this applies to you. The fingerprint, the key and this error message all come from the API replayer. On the browser side strict mode aborts the route instead, so you do not get a message naming the request — you get whatever your application does with a failed fetch, which is usually a spinner that never stops.

  Take the trace for those.

  GCanswered by Gio Castellano

  Reply

Have a different question? Ask it.