If I quit Obsidian. And then run this shortcut, I get an error and the obsidian note never gets updated. This seems repeatable.
I also have a feeling that sometimes when I run this shortcut, the daily note does not get updated. I need to do more testing though.
Hopefully it’s something I’m doing as the last thing I want is an unreliable way to update obsidian.
iOS 17.4.1
Latest Acctuons for obsidian
Obsidian 1.6.1
I’m seeing the same issue trying to update my daily note. I ran this last week with no issues.
iOS 17.5.1
Obsidian: 1.5.12
@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.
(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. ↩︎
Thank you for the great explanation.
Makes sense, I will try your work around.
I was excited to use this earlier , instead of my “put it in drafts to forget about” workflow. I typed maybe 4 or 5 lines, watched the shortcut do it’s thing and BOOM It’s gone.
I got the error about it being interrupted, see screenshot. I don’t suppose there is any useful logging we can see.
Thanks
Ok. This may have helped. Opening it first and doing a 1 second pause?
Is nobody else having issues with this kind of thing. I’m using an iPhone 14 so not very old device. Fairly snappy.
Yes, that’s why I said “an Open App block towards the start of the workflow” – it’ll open the app and give it some time to breathe in the background while you’re entering your data. By the time you hit “Ok” on that prompt it should be done launching for good.
BTW, iPhone 14 or not, if you have a lot of “heavy” plugins doing indexing during startup etc., combined with a big vault, fully launching can take a while. If that sounds like your situation, try deactivating every plugin but Actions URI, quit Obsidian, and test your workflow(s) again.
Me, I use only plugins on mobile that are actually necessary, to prevent that situation. 
Thanks. Makes sense. I will test some more. Still reeling from my outlook vs iCalendar issue 
