Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Replace register_noop_background_update with DELETE deltas #12940

Closed
clokep opened this issue Jun 1, 2022 · 7 comments · Fixed by #12954
Closed

Replace register_noop_background_update with DELETE deltas #12940

clokep opened this issue Jun 1, 2022 · 7 comments · Fixed by #12954
Assignees
Labels
A-Background-Updates Filling in database columns, making the database eventually up-to-date T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.

Comments

@clokep
Copy link
Member

clokep commented Jun 1, 2022

From a thread: #12899 (comment)

It seems that register_noop_background_update(...) could be replaced with DELETE FROM background_updates WHERE name = '....';

This would be nicer since we don't end up with dead code, register_noop_background_update was added in 6b02fc8 and from the conversation in #synapse-dev it seems like the DELETE approach was not considered.

@clokep clokep added the T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. label Jun 1, 2022
@clokep clokep changed the title Replace register_noop_background_update with DELETE deltas Replace register_noop_background_update with DELETE deltas Jun 1, 2022
@MadLittleMods MadLittleMods added the A-Background-Updates Filling in database columns, making the database eventually up-to-date label Jun 3, 2022
@clokep clokep self-assigned this Jun 3, 2022
@erikjohnston
Copy link
Member

AHA, I think I remember why we didn't do this as a delta: there have been times where we've told people to manually insert data into background_updates to re-run those updates for whatever reason. If they do that after the delta to delete the stale background update has run then we'll get an entry stuck in that table forever.

Not sure how much we care about that though.

@richvdh
Copy link
Member

richvdh commented Jun 8, 2022

AHA, I think I remember why we didn't do this as a delta: there have been times where we've told people to manually insert data into background_updates to re-run those updates for whatever reason. If they do that after the delta to delete the stale background update has run then we'll get an entry stuck in that table forever.

Have we ever done this for anything other than populate_stats_process_rooms and populate_stats_process_users (which we're not getting rid of)?

@erikjohnston
Copy link
Member

AHA, I think I remember why we didn't do this as a delta: there have been times where we've told people to manually insert data into background_updates to re-run those updates for whatever reason. If they do that after the delta to delete the stale background update has run then we'll get an entry stuck in that table forever.

Have we ever done this for anything other than populate_stats_process_rooms and populate_stats_process_users (which we're not getting rid of)?

Not sure, probably not? I think we should probably still do this change, but we should remember that after this change its no longer safe to just blindly tell people to insert stuff back into background_updates.

@clokep
Copy link
Member Author

clokep commented Jun 8, 2022

The only use I found that might refer to that while putting together #12954 was:

# we no longer need to perform clean-up, but we will give ourselves
# the potential to reintroduce it in the future – so documentation
# will still encourage the use of this no-op handler.
self.db_pool.updates.register_noop_background_update("populate_stats_cleanup")
self.db_pool.updates.register_noop_background_update("populate_stats_prepare")

Those don't seem to be in the docs anymore though, so...

@clokep
Copy link
Member Author

clokep commented Jun 8, 2022

We also now have an admin API for starting background jobs that we expect folks to have to run manually sometimes: https://matrix-org.github.io/synapse/develop/usage/administration/admin_api/background_updates.html#run

The job_name there doesn't actually get inserted, it gets mapped to the true job names:

if job_name == "populate_stats_process_rooms":
jobs = [("populate_stats_process_rooms", "{}", "")]
elif job_name == "regenerate_directory":
jobs = [
("populate_user_directory_createtables", "{}", ""),
(
"populate_user_directory_process_rooms",
"{}",
"populate_user_directory_createtables",
),
(
"populate_user_directory_process_users",
"{}",
"populate_user_directory_process_rooms",
),
(
"populate_user_directory_cleanup",
"{}",
"populate_user_directory_process_users",
),
]
else:
raise SynapseError(HTTPStatus.BAD_REQUEST, "Invalid job_name")

I think this gives us a little bit of protection too?

@clokep
Copy link
Member Author

clokep commented Jun 13, 2022

@DMRobertson thought that we might ask people to insert some entries into this for the user directory, I believe we used to but now have the above admin commands.

I did find some references in our upgrade notes though:

https://github.com/matrix-org/synapse/blob/master/docs/upgrade.md#incorrect-database-migration-in-old-synapse-versions

These ask to insert the current_state_events_membership and populate_stats_process_rooms in the background update table. Neither of these are no-op right now.

I think this is safe to do, so I'm going to merge it. 👍

@DMRobertson
Copy link
Contributor

DMRobertson commented Jun 13, 2022

@DMRobertson thought that we might ask people to insert some entries into this for the user directory, I believe we used to but now have the above admin commands.

Sorry, I should have mentioned this somewhere for completeness. I was thinking of here. It used to look like this and refer to a SQL migration file.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Background-Updates Filling in database columns, making the database eventually up-to-date T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants