I created a simple hook like feature (to simulate notifications) using sqlite3_preupdate_hook and noticed that it triggers for every row changed during a vacuum operation. The documentation states that:

registers a callback function that is invoked prior to each INSERT, UPDATE, and DELETE operation on a database table

This doesn't imply that it should trigger for a vacuum operation. In my opinion, I think it shouldn't because there's no way to distinguish between a vacuum and a regular INSERT, UPDATE or DELETE that actually changes data. Can this be considered a bug?

I agree that this behavior/doc combination is awry. It represents a library bug or a doc bug.

Hyper-technically, the doc does not say that the callback will not be invoked for other non-strictly-read operations, but it certainly implies as much. So this may be a doc bug because the doc should be clearer on this if it's not a code bug.

I suggest you use the post edit feature to prepend the word Bug: into the title. Somebody on the dev team is likely then to fix it, one way or the other.

If you look at paragraph 3 of section 3 in VACUUM, you will see that it can change rowids of tables having no INTEGER PRIMARY KEY.

I think you would agree that library users may well want sqlite3_preupdate_hook()-installed callbacks to be called in such a case.

I believe the doc on sqlite3_preupdate_hook() should indicate this possibility. And if it applies to your case, you may want to check to be sure that changing rowid values is not going to cause a problem. As you likely noticed in the sqlite3_preupdate_hook() doc, it is possible to determine what is about to be changed.

Also, I retract my title change suggestion.

Thanks for reporting this. Now fixed here:

https://sqlite.org/src/info/3c25cb4ab8885a50

This change means no pre-update or update hooks are invoked as part of a VACUUM operation, even if that VACUUM operation changes rowid values.