I’m trying to restore from a recent server to one built today. It’s failing with this error. I don’t see that anywhere in the Discouse code or in plugin code.
I’m not sure what to do next.
[20/9694]
ERROR: function discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() does not exist
EXCEPTION: psql failed: ERROR: function discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() does not exist
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:157:in `restore'
/var/www/discourse/vendor/bundle/ruby/3.
I’m lucky that the old server is still running. So I did launcher rebuild app to get the old server to the exact same version as the new installation. Then did another backup through command line. When restoring this backup on the new installation, everything went fine. You should try this. @pfaffman
Yikes I’ve run into this too. Trying to restore from a prod system to sandbox/dev. I’ve also double-checked all of the same plugins are installed.
Which other plugin uses this? going to check source right now…
Make sure the /var/discourse/shared folder was empty, or moved to a new location in case we need to restore
Initialized a new discourse instance using ./launcher bootstrap
Tried the restore again and still failed at same error message.
Then, When I did a dump of my good discourse instance, i found the actual command that creates the function. It is:
CREATE FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
RAISE EXCEPTION 'Discourse: old_notification_id in chat_mention_notifications is readonly';
END
$$;
ALTER FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() OWNER TO discourse;
Then retried the restore, and it all went well!
Now, I had the log where it failed and thought I could go back to it afterward, but the logs are reset with every Backup/Restore feature.
ENHANCEMENT: It would be nice to have a history of backups/restores. Maybe there is one, and I don’t know where it is.
DISCLAIMER: I am not a support person from Discourse, so I will not go into how to get into psql command line prompt to run the above commands. :
The problem is that a migration with an older date stamp was committed into tests-passed later on (@nbianca FYI), and this is not detected by the version metadata in the backup. I’ve kind of mentioned that here.
This is the solution. So you either need to get the commit hash from the instance server and build your new instance with that commit, or update the existing instance to latest, which will run that migration, and then take a new backup.
Yes, but sometimes you won’t be able to update the source instance. And in that case you will need to put the destination on the same commit as the source. So this is an exception to the regular situation where you can always do an implicit forward migration during restore.
I’m going to test this today, but my current assumption is that restoring works as soon as the destination site is fully up-to-date.
It looks like the problem is that the version check at the beginning of the restore doesn’t detect that the source actually had a newer DB schema than the destination.
Correct, and this is happening because the migration does not have the timestamp of the moment that it was committed, but the timestamp of the moment that it was generated. Most of the time that does not matter but in this case there was 7 weeks between those two moments.
Yes, that’s an unfortunate edge case. We can try to avoid it in the future or try to come up with a backwards-compatible solution to prevent it from happening again. However, I don’t think we can do anything to fix it in this case. That ship has sailed. Whatever we do, it will always require site owners to upgrade their destination site to the latest version.
Correct, this is an issue with this kind of techniques in general, it is a generic problem for Ruby on Rails and also for other AR implementations like PHP Laravel. And as you said, it doesn’t happen a lot, and once you realize what is going on it’s easy to work around during restore.
