All Pads are there again after Rebooting the Server

[q2apro]

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 also with the other plugin "adminpads2".

Or has the problem to do with Etherpad docker and the Postgresql docker?

How can I solve this, so deleted is deleted. Thank you.

[HarryBleckert]

It is no plugin bug.
Deleting pads works well with both adminpads2 and with this plugin adminpads3.

This plugin shows the current total number of pads above the list.
After deleting a pad the list updates automatically and total pad number will be reduced by 1.
Just tested again on an instance using also postgreSQL Server.

I'd guess you start docker with the same instance of DB as before deleting pads. But can't analyze your docker install.

I closed the issue.

[q2apro]

I have just tested it:

1. Created a backup of the database (A)
2. Used the plugin to delete about 30 pads
3. 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.

[HarryBleckert]

You are correct.
I just tested again and found same issue using a local postgresql server with local etherpad instance on Debian 11.
I have no easy way to test using another database.
I added "socket.emit('delete', padID);" to the deletion code in index.js but still same result.

Therefore I recommend you to open an issue with ep_adminpads2, as this is only a fork and I'm not really a nodejs or etherpad coder, but just someone who was pissed to have no sortable columns and not enough info in adminpads2.