What is responsible for this db-sync 'finalizer failure' message?

Troubleshooting
1

I noticed while debuging a custom function a while ago that every time my Org-roam database is synchronized, the following message gets printed to my messages buffer:

finalizer failed: (wrong-type-argument sqlitep nil)

As I was exploring the Org-roam database parameters lately, I stumbled upon the org-roam-db--connection variable, and noticed the last path to my local database was the only one using the ~ notation, since it is right after <finalizer> I thought I had the culprit.

#s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data
        ("/home/USER/.local/share/org/" #s(emacsql-sqlite-builtin-connection #<sqlite db=0x64432f287950 name=/home/USER/.emacs.d/.local/cache/org-roam.db> nil #<finalizer> "~/.emacs.d/.local/cache/org-roam.db")))

I thought it was odd, because I have not customized the org-roam-db-location variable. Anyway, I decided to set it from my config using (expand-file-name "~/.emacs.d/.local/cache/org-roam.db").

Changes took effect, but the message is still there after calling org-roam-db-sync. It has no side effect that I could tell so far, but no one likes stuff to fail in their Emacs, so I thought Iā€™d ask around.

Thanks for your time.

2

Whatā€™s the value of your org-roam-database-connector? If itā€™s not ā€œsqlite-builtinā€ and Doom Emacs lets you, I suggest you try the built-in SQLite. Does this make sense to you?

3

Thanks for replying.
The value for that variable is indeed sqlite-builtinā€¦

Just to make sure that part is clear, it is as far as I know only a failure message printed; apart from that, everything seems to be working fineā€¦
I would not even know about it if it was not for some unrelated debugging I did recentlyā€¦

4

Do you consider trying to move Doom out of the equation by removing it? I donā€™t use it and donā€™t have the message.

5

When you say ā€˜move Doom out of the equationā€™, you mean for testing ?
I would not actually know how to do that and still ensure org-roam loads. That would require some minimal config if only to get the files locations right I guess.

I actually have no idea how to do this ā€¦

6

Please provide the full error stack if possible

Thanks.

7

I am seeing this as well with org-roam-database-connector set to ā€œsqlite-builtinā€, Doom Emacs, Emacs 29.4 and org-roam 2.2.2.

There is no backtrace shown if (toggle-debug-on-error) is enabled.

8

@akashp , @fleimgruber has beat me to the punch, after testing with debug-on-error enabled, there is no debugger triggered for me either.

9

Unfortunately without knowing from where the error is coming from it will be extremely difficult to solve it.

The common thread that connects both of you is that both of you are using doom Emacs. I use vanilla Emacs and donā€™t have this issueā€¦

Would it be possible to zone in on the issue from your side, Figure out what is failing?

As a first step can you try changing the sqlite connector as an experiment?

10

Ok, what would be a valid alternative to sqlite-builtin ?

11

See documentation.
Try emacs-sqlite. It will compile if not available.

12

I had this problem since yesterday too, so I spent many a hours to figure out whats going ā€œwrongā€. There are a couple of reports regarding this, but nobody has been able to figure out what is happening yet.

This is not an issue, the message is being created from redundant garbage collection calls to close the connection to the database. Turns out org-roam manually closes the connection to the database when doing a sync

emacsql-close(#<emacsql-sqlite-builtin-connection emacsql-sqlite-builtin-connection-15920964e2c2>)
  org-roam-db--close()
  org-roam-db-sync((4))

But emacsql-close is also called as part of an automatic finalizer call

(defun emacsql-register (connection)
  "Register CONNECTION for automatic cleanup and return CONNECTION."
  (prog1 connection
    (oset connection finalizer
          (make-finalizer (lambda () (emacsql-close connection))))))

And it is this finalizer call that fails - because there is nothing to close - the connection has already been closed diligently manually by org-roam, there is no loose thread to clean up.

You can debug the close function to find out more for yourself-

(cl-defmethod emacsql-close ((connection emacsql-sqlite-builtin-connection))
  (message "running fn %s" (current-time))
  (condition-case err
      (if (oref connection handle)
          (progn
            (message "Closing SQLite connection handle: %s" (oref connection handle))
            (sqlite-close (oref connection handle))
            (oset connection handle nil)
            (message "SQLite connection closed successfully."))
        (message "No active handle to close for connection: %s" connection))
    (error
     (message "Error while closing SQLite connection: %s" err)))
  ;; Log backtrace
  (message "Backtrace:\n%s" (with-output-to-string (backtrace))))

If the message annoys you a lot you can modify this function to gracefully handle the case when (oref connection handle) is nil, that would suppress the message.

13 
(defun patch/emacsql-close (connection &rest args)
  "Prevent calling emacsql-close if connection handle is nil."
  (when (oref connection handle)
    t))

(advice-add 'emacsql-close :before-while #'patch/emacsql-close)

I am using this to suppress redundant calls to emacsql-close.
(oref connection handle) would return nil if connection to the database has been closed already. A before-while advice would be responsible for checking this, the original function donā€™t need to be meddled with. This should be safe for all practical purpose (i hope :smile: )

1 Like
14

Thank you for taking the time to report back on your findings in this thread; with an helpful and detailed walk through as always. It is good to know where the warning was coming from, and have a solution to suppress it too !
Unexplained warnings are always a source of concern that one is doing something wrong with their config, especially for users without a lot of experience with Emacs. :+1:

1 Like