Hi!
Over the last few days I’ve had problems with my AfO Shortcuts not being able to finish. They get to the stage where Obsidian is opened, but then nothing more happens.
What are common reasons for this and how can it be avoided?
Sounds like Obsidian takes the call but is not returning results…? The most common reason: Actions URI was disabled for some reason. An external call comes in → nothing is there to handle it → “
”
If Actions URI is indeed still running, and you’re willing and able, you could open Obsidian’s console (⌘⌥I) and see if there are any errors showing when you make a Shortcuts call and it hangs.
If you’re not comfortable doing that you could install my Logstravaganza plugin (which logs console output to a new note), enable it, restart Obsidian, then try a Shortcuts call or two. Disable the plugin, and send me the resulting note via feedback mail so I can take a look.
HTH!
Actions URI is indeed running, most of the time the Shortcut finishes when I launch the shortcut again.
This is happening on iOS. Could I access the console on mobile as well?
I think the easiest way is indeed Logstravaganza — I’ve yet to find a way to get the actual Web Inspector going in Obsidian mobile.
So this is what got written to the log when the shortcut just now wasn’t able to finish.
| Timestamp | Originator | Level | Message |
|---|---|---|---|
| 2023-10-12T15:21:49.783Z | plugin:logstravaganza | info | [Logstravaganza] Proxy set up (v1.2.0) |
| 2023-10-12T15:21:50.467Z | getToday@ | debug | [Calendar] Trying to switch Moment.js global locale to en-gb, got en-gb |
| 2023-10-12T15:21:50.504Z | registerRoutes@ | log | [Actions URI] Registered URI handlers: [“actions-uri”,“actions-uri/command”,“actions-uri/command/list”,“actions-uri/command/execute”,“actions-uri/dataview”,“actions-uri/dataview/table-query”,“actions-uri/dataview/list-query”,“actions-uri/folder”,“actions-uri/folder/list”,“actions-uri/folder/create”,“actions-uri/folder/rename”,“actions-uri/folder/delete”,“actions-uri/folder/trash”,“actions-uri/info”,“actions-uri/note”,“actions-uri/note/list”,“actions-uri/note/get”,“actions-uri/note/open”,“actions-uri/note/create”,“actions-uri/note/append”,“actions-uri/note/prepend”,“actions-uri/note/delete”,“actions-uri/note/trash”,“actions-uri/note/rename”,“actions-uri/note/search-string-and-replace”,“actions-uri/note/search-regex-and-replace”,“actions-uri/omnisearch”,“actions-uri/omnisearch/all-notes”,“actions-uri/omnisearch/open”,“actions-uri/daily-note”,“actions-uri/daily-note/list”,“actions-uri/daily-note/get-current”,“actions-uri/daily-note/get-most-recent”,“actions-uri/daily-note/open-current”,“actions-uri/daily-note/open-most-recent”,“actions-uri/daily-note/create”,“actions-uri/daily-note/append”,“actions-uri/daily-note/prepend”,“actions-uri/daily-note/search-string-and-replace”,“actions-uri/daily-note/search-regex-and-replace”,“actions-uri/weekly-note”,“actions-uri/weekly-note/list”,“actions-uri/weekly-note/get-current”,“actions-uri/weekly-note/get-most-recent”,“actions-uri/weekly-note/open-current”,“actions-uri/weekly-note/open-most-recent”,“actions-uri/weekly-note/create”,“actions-uri/weekly-note/append”,“actions-uri/weekly-note/prepend”,“actions-uri/weekly-note/search-string-and-replace”,“actions-uri/weekly-note/search-regex-and-replace”,“actions-uri/monthly-note”,“actions-uri/monthly-note/list”,“actions-uri/monthly-note/get-current”,“actions-uri/monthly-note/get-most-recent”,“actions-uri/monthly-note/open-current”,“actions-uri/monthly-note/open-most-recent”,“actions-uri/monthly-note/create”,“actions-uri/monthly-note/append”,“actions-uri/monthly-note/prepend”,“actions-uri/monthly-note/search-string-and-replace”,“actions-uri/monthly-note/search-regex-and-replace”,“actions-uri/quarterly-note”,“actions-uri/quarterly-note/list”,“actions-uri/quarterly-note/get-current”,“actions-uri/quarterly-note/get-most-recent”,“actions-uri/quarterly-note/open-current”,“actions-uri/quarterly-note/open-most-recent”,“actions-uri/quarterly-note/create”,“actions-uri/quarterly-note/append”,“actions-uri/quarterly-note/prepend”,“actions-uri/quarterly-note/search-string-and-replace”,“actions-uri/quarterly-note/search-regex-and-replace”,“actions-uri/yearly-note”,“actions-uri/yearly-note/list”,“actions-uri/yearly-note/get-current”,“actions-uri/yearly-note/get-most-recent”,“actions-uri/yearly-note/open-current”,“actions-uri/yearly-note/open-most-recent”,“actions-uri/yearly-note/create”,“actions-uri/yearly-note/append”,“actions-uri/yearly-note/prepend”,“actions-uri/yearly-note/search-string-and-replace”,“actions-uri/yearly-note/search-regex-and-replace”,“actions-uri/search”,“actions-uri/search/all-notes”,“actions-uri/search/open”,“actions-uri/tags”,“actions-uri/tags/list”,“actions-uri/vault”,“actions-uri/vault/open”,“actions-uri/vault/close”,“actions-uri/vault/info”,“actions-uri/vault/list-folders”,“actions-uri/vault/list-all-files”,“actions-uri/vault/list-non-notes-files”] |
| 2023-10-12T15:21:51.783Z | undefined | log | Dataview: all 1327 files have been indexed in 1.282s (1327 cached, 0 skipped). |
That’s all Logstravaganza could gather when the Shortcuts call stalled? That’s not much, hmm. 
I don’t think Actions URI was invoked at all, otherwise there’d be a log entry.
My guess is that the call came in before Actions URI was fully initialized. For starters, I would try to add a native Open App action to the very beginning of the workflow to open Obsidian. This will initialize Obsidian, and the next time a call to the app is made from the workflow, it should be fully up and running.
If that’s not it, try deactivating all non-essential plugins, i.e. anything you don’t need for that particular workflow, and try again. Maybe that’ll surface a misbehaving other plugin.
I’ve added an Open App action and a Wait 1 sec after. Hopefully that will help!
I’ve had the same issue, adding the open and a wait seems to fix it. Which means that the problem is that obsidian is not initialised before the uri action is called? Maybe the uri call should wait for the initialisation?
Actually that did not help. The I retried with logstravanza installed and looking at the log I’m confused. It has the failed call and the the successful call. It’s as if the failed call gets stuck in a queue.
LOGGING-NOTE (iPad).md (14.6 KB)
Welcome to the forum, @jolilius!
Which means that the problem is that obsidian is not initialised before the uri action is called?
Correct.
Maybe the uri call should wait for the initialisation?
The problem is that the companion plugin Actions URI can’t tell Obsidian what to do, e.g. wait for something, until it got initialized by Obsidian. And until Obsidian hands the incoming call to Actions URI, it doesn’t know that there is an incoming call. That’s what the Open-App-and-wait idea tries to circumvent/ solve/ work around, yeah.
As for your Logstravaganza output: It looks good to me. There are three lines for every incoming call (shortened for readability, empty line added to mark the two blocks):
| 2024-01-07T07:54:47.797Z | @capacitor://localhost/app.js:1:2008936 | log | Received callback URL obsidian://actions-uri/ …
| 2024-01-07T07:54:47.799Z | @capacitor://localhost/app.js:1:2009087 | log | Received URL action …
| 2024-01-07T07:54:47.872Z | @ | log | [Actions URI] Call handled: {"params":{"action" …
| 2024-01-07T07:54:49.062Z | @capacitor://localhost/app.js:1:2008936 | log | Received callback URL obsidian://actions-uri/ …
| 2024-01-07T07:54:49.062Z | @capacitor://localhost/app.js:1:2009087 | log | Received URL action …
| 2024-01-07T07:54:49.716Z | @ | log | [Actions URI] Call handled: {"params":{"action" …
The first two lines (@capacitor://localhost/app.js) are written by Obsidian itself: The first marks the incoming URI call before Obsidian tried to parse it, the second is the parsed form, i.e. after Obsidian has split it up into its constituent parts. The third line (containing [Actions URI]) is the plugin saying it handled the call successfully — check the logging note for the following bit, looking like this:
"handlerResult":{"isSuccess":true,"result":{"message":"Replacement done, note updated"},"processedFilepath":"0 Diary/2024/2024-01-January/W01/2024-01-07-Sunday.md"}
If you see handlerResult, then that means that Actions URI sent out a call back to AFO.
That said, it looks like the first call was successful but didn’t open the note in question after the fact.