Request body variables not taking latest values set through Pre-Script execution

[frank-duq]

Describe the bug When injecting env variables into your request body, and those values are getting initialized by the same request's Pre-Script through calls like await kr.environment.set(key, value);, the POST request being sent by keyrunner always inject the previous version of your environment variables "before' they are getting updated by the request Pre-Script execution (except, perhaps, the very first time you run the request and no existing environment variables have been defined/initialized yet..).

As soon as your variables are all defined with actual values at least once, then running the request will use the values of those env. variables at the time you push the Submit button, rather than using the newly environment variables' values that were just set by the request Pre-Script, which clearly defeats the entire purpose of running some Pre-Script to initialize values for that same request [body].

I can reproduce this problem every time.

To Reproduce Steps to reproduce the behavior:

1. Create a new POST Request (..target any existing or non-existing api URL, it really doesn't matter / we don't care if the request processing / roundtrip fails on the server side, since the problem is on the client side, e.g. keyrunner's api client generating and submitting the request, so it could be http://blablabla.com)
2. Inject an env. variable value into your post request body (any param key will work just like the one below), e.g.:

   {
   "reqPostBodyParamToSendToServerApi": "{{your_env_var_name}}"
   }

3. Add some pre-script to define and initialize such above env. variable:

   const envKey = 'your_env_var_name';
   const envValue = Math.floor(Math.random() * 10) + 1;                         // generate a random number between 1 and 10
   kr.console.log(`*** About to save env var [${envKey}] -> [${envValue}]`);    // log to the console our generated random number
   await kr.environment.set(envKey, envValue);                                  // save key/val to kr's env. store

4. Run/submit your request once, to get your env variable(s) initialized at least once. At this point, if you follow steps 6 to 9 below (e.g. skip over next step 5), you'll realize that the variable was not [yet] found in kr's env storage (even if it was literally just set from previous step 3...), so the post data won't contain the injected generated random number, but still the env var's placeholder, e.g. "{{your_env_var_name}}", and that env var placeholder is the string value sent to the remote server/api!
5. Re-run/re-submit your request a 2nd time (or as many time as you want, at this point you'll always get the same behaviour described right below..)
6. Open the keyrunner console
7. Starting from the end/bottom of the console log entries, locate the last log entry starting with "Sending Request Data: ..."
8. Expend this log entry node, and scroll entirely to the end/bottom of that node, until you reach the very last node key named "data", which represents the actual json data being sent as part of your request post body.
9. Observe that such json "data" being sent to the remote server/api won't contain the last generated random number just logged previously to the console by step 3- above, but actually, it contains the "previous" generated value from the previous execution that was stored in kr's env storage.

Expected behavior The env variables' values getting injected into the request body should always be the latest values generated by the same request Pre-Script.

Desktop (please complete the following information):

• OS: macos
• Version: 1.0.67

Additional Context Just a fyi, no pressure, but current issue is a pretty big show-stopper for us, entirely breaking our collection executions, alongside https://github.com/launchiamenterprise/keyrunner/issues/73, probably the 2 most important ones opened at time of writing imo, in terms of pure core API executions using keyrunner, at least for our use cases of running collection of api requests containing pre-script to initialize random data (through external faker lib) to be injected into requests' body. thanks

[launchiamenterprise]

@frank-duq Thanks for the clear description of the issue. This has been resolved with latest version ,where variables were not taking the latest values set through Pre-Script execution.

please update to latest v#1.0.69 and lets us know if you still find this as an issue.

[frank-duq]

@launchiamenterprise, thanks for looking into this.

Unfortunatelly, I've been testing with latest 1.0.69 using the exact same example that I put into ticket's description above, and I'm still experiencing the same out-of-sync data blocker issue.

Here's the problem, in action (with the new look & feel of the Console, confirming that I'm running on latest 1.0.69..):

The request:

The request's Pre-Script:

The request execution (Console): (see from that last screenshot above, the last pre-script execution generated number "7" which was logged to the Console, however, when looking at the request data that was sent to the remote server, value "5" was actually injected into the request body and sent to the server.....and such random number "5" was generated by the previous pre-script execution that I had run just before...)

---

Reopen issue?

[frank-duq]

After some further testing, I can also add that the problem described above seems generalized, e.g. it seems to be happening everywhere where there are interactions with the keyrunner environment variables, so perhaps it's a caching issue where new write operations to the keyrunner's env vars' storage does not invalidate its cache perhaps, and so any function after that trying to access the env vars' store and reading an env var will get an outdated value (from the cache?)...

Here's a screenshot down below showing that the same problem occurs even on 2 separate requests ran sequentially one after the other one.

Basically, the 1st request (Step 2- from the below screenshot) will set a keyrunner env var to a new value (from its Pre-Script exec.), and the 2nd request in this example (Step 3-) will read that env. var directly from the Request URL's env var's placeholder (injected as a url query param), BUT, the value won't contain the latest env var's value set from previous request (Step 2-); it will actually get injected an env var's value from a previous outdated one set by a previous execution of Step 2-, not the last one just executed right before, so this is 💯 breaking collection execution for which some data needs to be passed from one request to another...):

thanks

[launchiamenterprise]

@frank-duq Please update to v1.0.70. This issue should be fixed now. Let us know if the issue still persists.

[frank-duq]

Hmm, great, but it doesn't seem like v1.0.70 was officially released [yet], on the website's home, only v.1.0.69 is available at time of writing..

[launchiamenterprise]

can you please check now ? We had to perform a Cloudfront invalidation to refresh the actual S3 content

[frank-duq]

Yes, working, I could download v1.0.70 successfully, thanks.

And good news, this issue can finally be closed, it's working fine! (precisely when running each request of my collection sequentially one by one manually).

So let's close current issue, but I'll open a new one to explain the new issue I'm now having when running the whole collection in one shot (that was my ultimate goal to reach, but first I needed to ensure I could successfully run each request sequentially and manually one after the other one..).

It seems like maybe there's a similar (but different?) problem with the collection run, but perhaps it's only related to authentication, tbd.

[launchiamenterprise]

finally !! thanks for validating the fix. please raise a issue if you find any cases that we are missing and we can take a look

[frank-duq]

yes finally!!;)

sure, I just created another one, since it is kind of different, now that we've moving toward the Collection Run feature! ; ) ref.: https://github.com/launchiamenterprise/keyrunner/issues/90