Re-running Script Filter in my Workflow results in truncated or missing letters/characters (sometimes)

[luckman212]

Alfred 5.5.2257 + macOS 14.5

 

Strange bug(?) I am encountering... coming to ask for a sanity check.

 

I've been working on a new Workflow that runs a Script filter, and one path calls back to that original script filter step via External Trigger (direct mode) passing a variable for the arg. This is so it can launch an app in the background (Omnisearch inside of Obsidian) that exposes an HTTP API). I do this with a simple Zsh script that runs the app in the background using `open -b md.obsidian`. It mostly works... BUT

 

Once in a while, when the script filter re-opens, it's missing some characters from the search variable. 

 

E.g. if I typed `oo helloworld`, when the Script Filter reappears for the 2nd time, it only shows `hellow` in the box. Since I am passing these bits around using variables (not keystroke injection etc) I am at a loss to explain why these strings would be truncated or mangled. 

 

 

I have ALSO tried it using a simple "Show Alfred" object, to populate Alfred's box with the correct command/trigger keywords, and am experiencing the same occasional bug. So it's not specific to the use of External Triggers. Seems like something is eating these characters! No errors shown in the debug console. Not sure where to even go from here...

 

[vitor]

51 minutes ago, luckman212 said:

No errors shown in the debug console. Not sure where to even go from here...

 

What about a Debugger Utility to see what’s being passed in?

From your second screenshot, does that mean the Show Alfred utility is showing truncated text? If so, that could indicate something in the Run Script.

Are you able to create a short workflow to reproduce which does not depend on having those apps?

[luckman212]

Thanks vitor. I will try to make a demo workflow that does this -- it's a bit hard to reproduce exactly because it uses Obsidian + Plugin (Omnisearch) and may be specific to how long my vault takes to start up (about 4-5 seconds).

 

I will add some debugger steps, good idea. I don't know how to answer the question about the "show alfred" utility, I guess the answer is "yes" but I am not sure if it's the show alfred step or something about the script filter itself that is altering the query or causing the string to be eaten.

[Stephen_C]

7 hours ago, luckman212 said:

may be specific to how long my vault takes to start up (about 4-5 seconds).

It may be quicker and easier to rule that out first by using the Delay Utility to insert a pause at the appropriate point.

 

Stephen

[luckman212]

I think I figured this out! I believe it's caused by the Run Behavior of the Script Filter (Automatic delay vs. Immediate).

 

I made a test workflow to reproduce the behavior (which kind of makes sense now).

 

Please download from here:

https://github.com/luckman212/alfredworkflows/raw/master/funny business.alfredworkflow

 

There are 2 different triggers:  .f1 (delayed) and .f2 (immediate)

 

Here's a video that should illustrate...

https://github.com/luckman212/alfredworkflows/commit/9d85590e91ea1264c09fa66e9b9f9bd2b22b50ba#commitcomment-142329534

 

This does bring up a question: Should there not at least be an option to update {query} ($query in shell scripts) to always match whatever was in Alfred's window at the instant the ENTER key was pressed? I understand not wanting to change the current behavior if, for legacy reasons, it's always been that way (I honestly can't remember).

 

But perhaps either of these would be a good idea?

• adding a "{query_executed}" or something that captures the actual value that was entered
• or, adding an option to the Script Filter, something along the lines of "Use value entered rather than the delayed value derived by the Script Filter"

[vitor]

Indeed, it has always worked like this. I remember when I noticed. Ultimately, it’s useful to remember we’re using a Script Filter; it’s designed to filter for entries. With that in mind it becomes clearer why it works as it does: the object cares about the results—arg, which can be literally anything—and not what is typed. It makes sense, though as hackers it’s hard to resist the temptation to bend the tools to their limits to see what behaviours we can come up with. I definitely get that.

Funnily enough, while I remember the original post I don’t remember what prompted it. Maybe Rename Action? But that has since evolved so much in terms of functionality and speed that the feature wouldn’t really be useful.

So, what does your original Script Filter do? Perhaps there’s a way to speed it up. Or maybe there’s a method to detect if you’re waiting for more information before continuing (I use such a technique in Google Suggest). Or maybe the solution is an initial Keyword Input that later goes into a Script Filter. Many possibilities, which we can narrow down after defining the exact scope of the problem.

[luckman212]

Those example workflows are a hoot! I 99% solved this for now by just switching the ScriptFilter behavior to "Terminate/immediately":