Bug with Environment Variables and Configuration Builder

[gloogloo]

I just found what seems like a bug when setting an environment variable from an external script. I have created a “Test” workflow which you can download below. Basically, I have a script action which loads a .js script externally. The script is loaded from within a bash script action as:

/usr/bin/osascript test.js "$1"

 

At first, the Javascript sets the environment variable correctly. I can use the environment in other action blocks. HOWEVER, the moment that I add ANY block in the configuration builder, I can no longer use it in other action blocks, at least not always—even though it seems correctly set, since I haven’t changed anything.

 

Test Workflow

 

A video showing the bug in action.

 

I am not using Alfred preferences on any cloud service.
Alfred 5.5 (2257)
Sonoma 14.5

[vitor]

Thank you for the explanation and the report. I’ll take a look and possibly open an internal issue. It may be related to how setConfiguration works for both configuration and environment variables.

May I ask what’s your use case, though? Configured Environment Variables are typically for fixed variables, not for something that changes dynamically. Especially if you’re setting them to not export, this approach seems inefficient. If you want to set an environment variable that will be valid during a workflow’s run you should instead set it in an Arg and Vars Utility, or (if you need it dynamically) send it as JSON from. Note you don’t have to use the JSON Utility to do that.

[FireFingers21]

@vitor This has been an issue for years, where Alfred is often slow to notice programmatically modified variables. I think this forum post is what first validated the issue for me, where I learned that a solution to bypass the problem is to force a reload of the workflow by just tacking on the "reload workflow" AppleScript. There are other discussions of this behaviour dotted throughout the forum, a more recent one seems to be this forum post.

 

This is actually an issue I ran into with my linkding Bookmarks workflow, where I needed a persistent variable to track a timestamp of when the cache file was last updated. I tried using an environment variable, but my workflow's reload function works in a loop, and forcing a reload so Alfred can immediately notice that variable breaks that loop. My solution was to ultimately just write the variable to a file, then use the source command to fetch it when I need it.

[gloogloo]

Thanks @vitor, I was just trying to update an older workflow where I did realize I was incorrectly using the Environment Variables set in this way, but I was really curious as to what was going on (because IMO, it should have still worked)... that's why I tried to figure out what was causing it. I've since updated my workflow to return normal variables in JSON form. So, this is not something I need right away, but I still think it's something that would be handy to have working properly for other use cases. 

 

Thank you @FireFingers21, it's great to know about the "reload workflow" workaround. 

[vitor]

On 7/26/2024 at 8:11 PM, FireFingers21 said:

I needed a persistent variable to track a timestamp of when the cache file was last updated.

 

One neat way to do that is check the file’s modification date. That way you don’t need to keep track of a different file or variable, the information is in the file itself. You can touch it to force update the timestamp when needed.

 

On 7/26/2024 at 8:11 PM, FireFingers21 said:

I tried using an environment variable

 

You can do both. Use AppleScript to update the environment variables and send the same information to the next object in a Utility or as JSON.

 

Note these do not invalidate your points, I’m offering alternatives you may not have considered. I’ll still look into it and discuss internally but it’s important to note AppleScript is itself a slow language and if I recall macOS file system events have been unreliable at times. In general, if you’re changing the workflow itself as you run it, it seems reasonable those changes may not be immediate for performance¹ and stability².

 

---

 

¹ Imagine never being able to optimise by cache any information and having to read something over and over in the off chance an external process changed something mid run.

 

² Imagine (as way of analogy) running a script and changing parts of it as it runs. Results could be unpredictable.

[FireFingers21]

11 hours ago, vitor said:

One neat way to do that is check the file’s modification date.

 

It's funny you mention that, I already do that for all the background functions of my workflow. Apparently I never realized I should also do that for the user-facing parts too 😆. Thanks for bringing it up!

[Floating.Point]

I ran into this issue with my Icon Generator workflow- programatically updating the environment variables for the user selected colours. I got around this exactly as Vitor advised here, by both setting the environment variables via the Arg and Vars utility as well as updating it via AppleScript. The result was a persistent change to the value as well as it being immediately available to the later nodes in the workflow. 

[vitor]

The original issue reported by @gloogloo, where adding the configuration builder item may make the environment variable not be correctly read, should be fixed on the next release.