Alfred 5 symlinked workflows don't automatically reload [Workaround in 5.1 b2129 pre-release]

[Gary King]

I have a workflow in Alfred 5, with a Run Script item. This workflow is also in a Git repository.

 

While working on the workflow, I'll occasionally swap to another branch, which also changes the code run in the Run Script item. Previously in Alfred 4, after I changed Git branches and run the Run Script item, the new value would be used immediately.

 

However now with Alfred 5, the value for this Run Script item only updates after I restart Alfred.

 

How can I make Alfred automatically update the value, rather than using a cached copy? This makes debugging workflows more difficult now, in Alfred 5 compared to Alfred 4.

Edited July 25, 2022 by Gary King

[Vero]

@Gary King Could you update to the 5.0.1 pre-release? I believe this is fixed in that build

[Gary King]

@Vero Thanks that seems to have worked. Is there a faster way to refresh workflow items than closing and re-opening Alfred preferences though? Such as either a Command-R refresh shortcut, or clicking on another workflow then clicking back to the original workflow.

[Andrew]

@Gary King the update into Alfred's preferences should be instant, but this may be delayed if you're using a syncing service which isn't notifying Alfred of changes.

 

Are you syncing prefs?

[Gary King]

I'm not syncing prefs. I'm on Alfred 5.0.1.

 

I have a "Keyword" workflow item with "ica" as the shortcut, which leads to a "Run Script" item. Depending on the branch in my Git repo, the "Run Script" value will be different. 

 

If I check out another branch, then the value in "Run Script" only updates when I close the Alfred preferences window and re-open in. In Alfred 4, however, I simply had to click on another workflow then click back to the original workflow, for the "Run Script" value to update.

 

In addition, after closing and opening the Alfred preferences window, the "Run Script" value is indeed updated, but most importantly, using the "ica" keyword still executes the previous "Run Script" value, according to the Alfred debugger.

[Gary King]

Just now, I checked out from Git an older commit for my Alfred workflow, and I had to restart Alfred for it to identify the change. I assume that Alfred is caching the values for an improvement in performance, but it's costing development time for workflows. It would be nice to have an option for developers to immediately update the workflow cache.

[Andrew]

@Gary King could you email the exported output from typing ?diagnostics into Alfred so I can take a look at your configuration?

 

When it comes to your workflows, do they exist in Alfred's default location (local app support folder), or are you symlinking the workflows in?

 

Cheers,

Andrew

[Andrew]

Further to this, in my testing right now, I have two instances of Alfred Preferences open, and editing one (including moving items around) are reflected in near real-time on the other Preferences. I'd like to get to the bottom of why this isn't the case on your Mac.

[Gary King]

The issue appears to be caused by the fact that I'm symlinking my workflows in. Specifically, in the `/Users/gary/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows` directory, I have several normal folders in there for workflows, and I have a handful of symlinks in there, which point to other directories on the same volume, for other workflows that I also have.

 

I tested the issue by creating a new workflow in Alfred, and then creating two commits that changed the Alfred data. When I swapped between the commits, the Alfred data was updated instantly. However, when I then moved this workflow to another directory, and symlinked it back in, performing the same test did not update Alfred, indicating that the issue is caused by the fact that the workflow uses a symlink.

 

Is it possible for you to fix this in Alfred? Rather than requiring that all projects needing to be moved to the Alfred dir. Of course I would prefer to continue using my symlinked approach for workflows, if possible.

[Andrew]

While this is something I'd like to solve, it will take some consideration as it's a non-trivial issue if I want to keep the performance [bloat] down.

 

Alfred gets finite filesystem notifications from within the Alfred preferences package, which is how he reloads on an underlying change. If I were to widen this, it doesn't scale particularly well.

 

I do wonder, would it force a reload if you deleted and recreated the symlink?

[Gary King]

Yes, unsurprisingly, if the workflow is symlinked, and I swap to another commit, then the workflow data is not updated, but if I delete the symlink and re-create it, then the data is updated in Alfred. That would be the equivalent of removing and adding the workflow back to Alfred, so I imagine that it's expected that Alfred would read the whole workflow upon such an action.

 

I have had my workflows symlinked to Alfred for years, and in Alfred 4, it had no problems immediately updating workflow data, even from symlinked workflows.

[Andrew]

The underlying framework for maintaining a relationship between Alfred and the filesystem hasn't changed between as early as Alfred 2 up to the current release, so it comes as a surprise that the behaviour has changed. It could very well be a change in a macOS update which has altered the behaviour you're experiencing.

 

Keep in mind that Alfred hasn't actually ever officially supported symlinked workflows into the workflow folder, which is why I'm trying to find you a workaround until I can come up with something more official.

 

Perhaps for now, edit your scripts which are updating the workflow from github to recreate the symlink, which will cause the reload into Alfred. I'll have a chat with @vitor about the best way to move forward with github workflows distributed outside of the workflow folder.

 

Cheers,

Andrew

[Gary King]

It's possible that the behavior changed between one Mac OS version to another, because I did upgrade my MacOS recently. Here's my timeline of recent events:

 

- 2014 to July 8, 2022: I was using a Mac Mini 2012, running MacOS Catalina up until the end.
- July 9, 2022: I migrated to a Mac Mini 2020, running MacOS Monterey (therefore skipping over Big Sur).
- July 24, 2022: I upgraded from Alfred 4 to Alfred 5.
- July 25, 2022: I noticed that changing Alfred data from outside of Alfred was not being reflected by Alfred. It's possible this issue existed since I upgraded to Monterey on July 9, but I first noticed the issue on this date, July 25.

Edited August 6, 2022 by Gary King

[Andrew]

@Gary King I've now added an option to "Reload" the workflow in the popup menu of the workflow list in Alfred's preferences in the 5.1 b2129 pre-release.

 

We also have a workflow in the works for when 5.1 is released which will give you a faster way to reload specific workflows.