Why are file links being created when IDs exist?

Following the inspiration of this post, I have been trying to use only ID links in my org-roam files. I have org-roam-prefer-id-links set to t. And my org-roam-capture-templates put an ID property at the top of every new file.

But when I create a new file testa a via org-roam-find-file, and then in filea I call org-roam-insert, what’s inserted is a file: link.

:ID:       2021_0322_201447
#+title: testa

:ID:       2021_0322_201506
#+title: testb

I see that in the implementation of org-roam-insert that the 5th optional argument is link-type:

(defun org-roam-insert (&optional lowercase completions filter-fn description link-type)

which defaults to type file::

LINK-TYPE is the type of link to be created. It defaults to \"file\".

Am I wrong to think that org-roam-prefer-id-links should override this default and produce an ID link in this case? Or is that effect achievable via some sort of alternative configuration I’m as-yet unaware of?

This is likely because your database isn’t synced yet, so Org-roam thinks the ID doesn’t exist.

(setq org-roam-db-update-method 'immediate)

Should alleviate some of the surprises.

Thank you for the suggestion, Jethro. (and thank you and Zaeph and everyone else for org-roam! :))

Even with (setq org-roam-db-update-method 'immediate) I was still getting occasional file: links, and then I happened upon what I think solved the problem: when I save the capture buffer (C-x C-s) before exiting out of it (C-c C-c), the link in the referring document always ends up being an id: link, but when I don’t save first, it is always a file: link.

So, I hypothesize that the order of operations on leaving the capture buffer is such that, the link is generated for the new file prior to the file being saved and the database being updated?

Whether that hypothesis is correct or not – apparently now all I need to remember to do is C-x C-s before exiting the capture buffer, and I will end up with id: links as desired.

Thanks again

Org-roam operates on the file state on-disk. If you don’t save the file after capture, then to Org-roam, the file isn’t updated yet, and the database also won’t be. That’s the trouble with this sort of dual representation.