Originally posted at adminspad3: HarryBleckert/ep_adminpads3#14
When I reboot the server, all pads that I have deleted with the plugin are again in the list at /admin/pads.
Is this a bug of the plugin? It happens with the plugin "adminpads2" and "adminpads3".
I have just tested it:
- Created a backup of the database (A)
- Used the plugin to delete about 30 pads
- Created another backup of the database (B)
Result: Backup (A) contains the same pads as backup (B) inside db etherpad.
But at /admin/pads it shows only the pads that were not deleted.
Either the Postgresql db dump has an issue, or the deletion does not really delete.
I could not find the source for socket.emit('delete', padID); to check what is going on with the deletion.
Notes:
When restarting the Etherpad Docker, the deleted pads do not show up (as expected).
When restarting the Postgresql Docker, the deleted pads do not show up (ax expected).
However, when rebooting the server, the deleted pads show up again (!)
So some "data recovery" seems to happen with the server reboot?! ... and all new changes to pads are also there.
Could this have to do with the issue:
Extensions and Custom Code: If you have custom extensions or code that is run during server startup or shutdown, it could potentially cause changes. For example, if you have a script set up to run on server startup that performs some data modifications, those changes would occur during the restart.