heya, when generating stub mappings for a recording,

serveEventsToStubMappings

in the Recorder generates the stub mappings from the serve events in reverse-chronological order, and thus passes them to the transformer in reverse-chronological order. is this expected and/or intentional? is it something that you'd accept a patch for? alternatively, is there an existing extension point to customize this order? i'm writing an extension that matches & propagates data through the sequence of requests. it depends on being able to capture data from requests earlier in the chronology to match that data in requests later in the sequence, so it's a bit of a show-stopper for me 😅. i can think of a hack or two (probably storing all the stub mappings passed to the transformers in a list of my own, figuring out when the last call happens, and re-sorting/processing them all during that final call) but i'd like to avoid it if possible.

It’s intentional, so it needs to stay that way I’m afraid. I would suggest trying find a way to make the stubs mutually exclusive via matchers so that insertion order doesn’t matter rather than trying to hack the insertion order.

hmm fair enough! perhaps as long as all the request data can be parsed out before stub mapping generation then it wouldn't be a problem.