Jump to content

Alfred 5 symlinked workflows don't automatically reload


Recommended Posts

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 by Gary King
Link to comment

@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.

Link to comment

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.

Link to comment

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.

Link to comment

@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

Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment

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

Link to comment
  • Andrew changed the title to Alfred 5 symlinked workflows don't automatically reload
Posted (edited)

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 by Gary King
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...