Need to regenerate records if `matchRequestsBy` changes

Description

If I understand things correctly, having the id hardcoded in the har files makes it so that when matchRequestBy changes no entry is valid. The recordings are in fact still viable but since the id is generated based on matchRequestBy all recordings need to be recreated.

That becomes a big problem when you have a lot of recordings, even the slightest change to matchRequestBy requires to regenerate everything!

I use matchRequestBy to ignore things that are dynamic or may change between two runs. Dates, tokens, some ids, etc… The config is mostly very static but in the case where it needs to change it creates a massive break.

What I would like to see is har files be a pure raw recording of the requests and be independant of the matchRequestBy.

Shareable Source

All entries in har files have this:

{
  "_id": "1f62d02515e4ee31cf40fafc4d01f127",
  "request": ...
}

[jasonmit]

@stephenh _id could be computed at runtime it’s just not the implementation today.

If there is enough interest, I think we could make the necessary changes but the work involved to get there is pretty significant.

[skimi]

They already are. The ID is generated every time a request goes through Polly and is stored with the recording.

What I mean by when pollyjs starts is when the persister is instantiated. At that time it could generate the id for all its records (might be long, don’t know). That way the id would always be generated with the latest matchRequestsBy config.

If the ID changes, we have no way of knowing if the previous recorded data is still valid so the safest assumption is to fetch a new one that will then truly match the ID.

Since the har file is a raw recording of the request it would still have all the necessary information needed to generate a new ID that would match the new matchRequestsBy setting. Instead of fetching again regenerate the IDs for the existing recordings. Then maybe fetch if it still does not match.

Anyway, I know it’s an edge case. My first assumption that any changes to matchRequestBy require a record of everything is actually false. Requests that are not affected by the change won’t actually need to be re-fetched. I just had a case where a single change affected everything.

If possible, maybe pollyjs could not hardcode the id in the har-file. That would avoid a few fetch sometimes