Delayed action sees stale environment variable

[ndirons]

I have a script filter which depends on cached JSON input, because it takes a couple of seconds to generate new data, and the results change infrequently. I thought I'd get the best of both worlds by generating the data if the cache is not found, or reading the cache if it's present, while also firing off a task to refresh in the background for use the next time the workflow runs.

 

However, if the cache isn't found and I have to generate it before I can show the script filter, then I don't want to regenerate it again almost immediately. I handled this with an environment variable, and I modify its value to tell the delayed action whether it should rebuild the cache or just exit.

 

Surprisingly to me, the delayed action never sees a change in the environment variable's state, even when it's executing seconds after the value changed. Testing suggests that a delayed action will always see env vars as they existed at the moment the delay was triggered, not when the action runs. Is this expected behavior? If so, the documentation of environment variables as "global" could use some nuance.

 

I'm on Alfred 5.1.3 (2175), and the behavior is consistent on 14.0 and 13.5.2. Here's a sample workflow: https://www.dropbox.com/scl/fi/vzk8u8vp45a78jhryzlk0/Env-Var-Delay-Sample.alfredworkflow?rlkey=pa0sxraiezoks4anj6c92tupq&dl=0

 

Thanks for your time.

[Andrew]

@ndirons Looking at your workflow, it's working as expected.

 

Any variables set in one connection stream do not affect other connection stream. Setting the variable in the top Run Script will not be seen by the delay object and subsequent connected items. This is by intrinsic design to allow for predictable logic building throughout different connections, while also allowing for shared usage of objects within a single workflow.

 

Rephrased in the context of your workflow, you could have many outputs from your keyword, all connected to a middle Run Script which sets a different variable, then all connected to a final Run Script which acts on the current context based on what was set upstream:

 

 

Cheers,

Andrew

[ndirons]

OK, I appreciate the explanation. Though as I said above, to document environment variable as "global" seems to elide context, at best.

[vitor]

What’s described as global in that page are the Workflow Environment Variables you set in the [x], not the variables set in a stream. The former are set whenever the workflow is run; the latter only when relevant.