Strange Mock Response Behavior

🙋 Help
1

Hello Postman friends! One of the developers at my company is seeing some strange behavior with mock requests. The problem is intermittent, so I’m wondering if there’s some kind of caching issue in addition to a potential bug.

The situation is this: we have a POST URL that includes two variables:
{{BaseEnvironmentUri}}{{uriPrefix}}/Queue/StatusSummary
The request itself works OK, but when he creates an example request with this URL and then uses it in a mock request, he gets this response:
{
“error”: {
“name”: “mockRequestNotFoundError”,
“message”: “Double check your method and the request path and try again.”,
“header”: “No matching requests”
}
}

If he changes the example request to only use one variable, and uses the hard-coded value for the second variable, then he gets the correct mocked response.

However, this issue has been very difficult to reproduce, because I’m only seeing the problem intermittently. I’m wondering if the mocked response is being cached, so that there are times when I get the correct response when I’m using two variables, and there are times when I get the error response when I’m using one variable.

I’d love to find out if caching is causing the intermittent behavior, and if we do indeed have a bug here. Thanks!

2

Hi, @kjackvony!

I suspect what’s happening here is that the side-by-side variables, {{BaseEnvironmentUri}}{{uriPrefix}}, are getting matched against the base URL only (e.g., https://<uuid>.mock.pstmn.io) as there are no path separators. If your uriPrefix value is a path (e.g., /v1), this would essentially negate what you’re trying to accomplish with that variable.

I was able to reproduce this issue. One trick you can do here is to put a / between your variables in the request URL field of the example (e.g., {{BaseEnvironmentUri}}/{{uriPrefix}}. You should be able to keep your variable values exactly as they are, and it should match just fine. This will force uriPrefix to match the first path segment.

Hope this helps.

Best,

Kevin

3

Hi Kevin- Thanks for the swift response! The potential workaround of using the slashes between the variables didn’t work for us, but the dev seeing the issue feels a lot better that you were able to repro it and that you have explained what’s going on. :slightly_smiling_face: