@g6phf @bennewton999 It’s quite likely that Obsidian wasn’t fully up (yet / anymore) and receiving when the API call by AFO came in. The error hints at that – when Obsidian doesn’t return the result that usually means the companion plugin isn’t running.
Before I explain the problem in detail: The workaround is to add an Open App block towards the start of the workflow; this’ll help ensure Obsidian is receptive to API calls once the AFO actions are executed. That usually does the trick, if it doesn’t, consider adding a Wait action right that to give Obsidian a bit more time to launch.
(Update: See this knowledge base article for related tips – How can I check if Obsidian is already running? - ActionsDotWork Knowledge Base.)
So here’s the explanation of why this problem occurs: Any app that needs to talk to the Obsidian API basically just tells the OS “Here’s a piece of info for Obsidian” (because that’s dictated by the type of API). iOS/macOS then brings Obsidian to the front (or launches it, if necessary), and hands it the API call. Obsidian deals with the AFO call by passing it on to Actions URI, which uses the same mechanism to send the result back to AFO. Usually, that works fine.
But when the app needs to be launched, things can get tricky. The OS doesn’t really wait for Obsidian to fully wake up, it just passes the call along. Now Obsidian has to keep track of that API call while it launches, indexes, and maybe syncs. Afterwards, it has to initialize all its active plugins, then decide where to send the API call internally. And during all those steps, sometimes the call gets lost.[1]
So AFO can only send out the API call, and then it’s relegated to waiting. Obsidian is a black box because iOS/macOS. And maybe the result comes back – or it doesn’t.
Unfortunately, there’s not much I can do about that.
I really dig Obsidian (obvs) but its mobile app has some issues which are a side-effect of the tech stack they’re using to build the app. ↩︎