Hey, I’m currently contemplating an enhancement to WireMock Scenarios as was hoping to get some feedback. Background: some folks who are running WireMock in shared environments (or ones with concurrent activity) find it a problem when a scenario’s state is updated by another user/session, affecting theirs. I’m proposing to support adding specific request parameters (headers, query, cookies etc.) to the scenario’s state key, so that e.g. if you include

JSESSIONID

as an element, you’ll get a unique state machine for every value of the session key, rather than a single global state machine (for this scenario). I contemplated just making the scenario key templated, but realised it might be good in future to be able to retrieve scenarios by name via the API and see a breakdown by session/token/whatever. So I think the additional key elements should be a list of request parameter types/keys. So, the JSON API would look something like this:

{
  "scenarioName": "To do list",
  "requiredScenarioState": "Started",
  "scenarioStateKey": [{
    "type": "cookie",
    "name": "JSESSIONID"
  }],
  "request": {
    "method": "GET",
    "url": "/todo/items"
  },
  "response": {
    "status": 200,
    "body": "...
  }
}

Have any of you experienced this particular issue before? If so, do you think this be a good solution?

What would the full list of scenario state key types be? I'm guessing: • cookie • queryParam • header

I think those 3 would be sufficient. I’d want to see some real-world usage before adding e.g. the ability to select body elements.

It looks like you're planning to allow multiple things in the

scenarioStateKey

- do you expect that to be necessary?

I can’t think of any obvious scenarios, but OTOH it’s not that much more complicated to permit >1 key element, but might be a pain to add that later if it turns out to be needed.

I wondered if we could start with that, then if someone has a concrete requirement you could add

"scenarioSessionKeys": []

and the former would become a shorthand for the latter with one key.

Do you think it’s clearer describing it as “session key(s)” specifically or something more generic? I’m wondering if people will be confused/put off if the thing they’re segmenting on isn’t a session per se.