Race condition saving environment variable with pm.environment.set in post-response script

[HansFalkenberg-Visma]

Is there an existing issue for this?

• I have searched the tracker for existing similar issues and I know that duplicates will be closed

Describe the Issue

Using scripts to store variables in the active environment is unreliable. It has a chance of silently ignoring the save. The chance appears to be timing related, so it would appear to be a race condition.

This is a critical issue. When a request has completed successfully, we must be able to trust that the script has actually performed the code that ran without any error indication.

For example, we have a request that will do a lookup on an key A to convert it to key B. Both keys represent the same entity, but in different APIs. Then we have another request that mutates the entity using key B. If the key B value hasn't actually been stored in the environment, I will mutate some unrelated entity that I've happened to have worked with previously.

The past week I've seen this happen occasionally, without being able to pin it down. In 11.75.3 today it seemed to happen continuously for one of my calls. I upgraded to the latest version (11.75.6) and observed the value not being saved 11 out of 12 times.

Steps To Reproduce

This has been consistently reproducable, but with wildly varying chances of it occurring. In some of our real requests I'm seeing it more often than not. The highest chances seems to be with an mTLS POST request. https requests may be higher than http. That's more of a guess though, not necessarily an indication of anything.

Full, minimal reproduction (any backend/endpoint will do, but if you have NodeJS installed then this is fully self-contained):

1. npm install -g http-server && http-server
2. Create a new environment and set it active
3. Create a new collection
4. Create a new request for http://localhost:8080
5. Save the script below in Post-response (I didn't test whether Pre-request has the same issue)
6. Send the request repeatedly
7. Watch the Console. Without a bug it should alternate between printing B's and a's. But within 100 sends I've always seen it print the same value several times.

const prev = pm.environment.get('race') ?? '';
console.log(prev);
const next = new Date().toISOString().substring(11,23) + (prev.includes('a') ? ' BBBBBBBBBBBB' : ' aaaaa');
pm.environment.set('race', next);

Invoking a request repeatedly is not necessary to trigger this bug, only to consistently find it. It has happened several times for actual requests that were sent once without anything else happening.

Screenshots or Videos

Operating System

Windows

Postman Version

11.75.6

Postman Platform

Postman App

User Account Type

Signed In User

Additional Context?

Autosave is disabled.
Windows version is 25H2.
Using a workspace in an enterprise agreement.

pm.environment.get(...) right after the set has always returned the value that was set. So it seems the environment works locally in the script, but then fails to be persisted.

[DSchau]

@HansFalkenberg-Visma hey thanks for the detailed reproduction. We'll investigate, get back to you if we need more detail, and do our best to fix.

Appreciate the helpful reproduction and thorough notes, in particular.

cc @appurva21 @codenirvana