[bug] Attachments disappearing with delete and redraft

lamp commented

2024-05-09 23:23:08 +00:00

Your setup

From source

Extra details

Ubuntu 23.04

Version

c02e3432d9

PostgreSQL version

15

What were you trying to do?

Post post with attachments
Delete and redraft post with attachments
Wait a minute or a few minutes
Post it

What did you expect to happen?

Post gets posted same as it was in editor

What actually happened?

Post is missing attachments. Or if I added attachments, old attachments are missing.

Logs Additional information

Upload filters are Exiftool.StripMetadata and Dedupe.

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup From source ### Extra details Ubuntu 23.04 ### Version c02e3432d97f95a85c2684e845fa37d0228e495d ### PostgreSQL version 15 ### What were you trying to do? 1. Post post with attachments 2. Delete and redraft post with attachments 3. Wait a minute or a few minutes 4. Post it ### What did you expect to happen? Post gets posted same as it was in editor ### What actually happened? Post is missing attachments. Or if I added attachments, old attachments are missing. ### ~~Logs~~ Additional information Upload filters are Exiftool.StripMetadata and Dedupe. ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

lamp added the

bug

label 2024-05-09 23:23:08 +00:00

floatingghost commented

2024-05-09 23:29:14 +00:00

Owner

delete and redraft isn't actually a backend function, it's the frontend just deleting the old post and giving you a form prepopulated with the old post's data

as such, if you have cleanup_attachments turned on, this would be expected behaviour

delete and redraft isn't actually a backend function, it's the frontend just deleting the old post and giving you a form prepopulated with the old post's data as such, if you have `cleanup_attachments` turned on, this would be expected behaviour

Oneric commented

2024-05-10 00:01:53 +00:00

Member

ig (if Oban allows this) we could delay deletion by some offset to give “Delte & Redraft” a better chance to work. But, it will never be possible to guarantee attachments still exist if redrafting takes too long (even if the server was informed about the intent to redraft, eventually it will have to assume redrafting was cancelled)

EDIT:
The scheduled_in/_at job properties sounds (but i’m not 100% sure) as if Oban will try to execute them precisely at the desired time, not sure how this interacts with concurrent job limits.
If they are unsuitable, first running a job which just snoozes itself and then on the next run enqueues the actual job should work (snoozing is documented to postpone by “at least” the specified duration)

EDIT2:
schedule_in/scheduled_at uses the same internal mechanism as snooze and is the officially blessed waay to do this. scheduled_at can also be used with the replace-on-unique-conflict mechanism to ensure the delay elapses from the last request related to a resource.

ig (if Oban allows this) we could delay deletion by some offset to give “Delte & Redraft” a better chance to work. But, it will never be possible to guarantee attachments still exist if redrafting takes too long (even if the server was informed about the intent to redraft, eventually it will have to assume redrafting was cancelled) EDIT: The `scheduled_in`/`_at` job properties sounds (but i’m not 100% sure) as if Oban will try to execute them precisely at the desired time, not sure how this interacts with concurrent job limits. If they are unsuitable, first running a job which just snoozes itself and then on the next run enqueues the actual job should work *(snoozing is documented to postpone by “at least” the specified duration)* EDIT2: `schedule_in`/`scheduled_at` uses the same internal mechanism as `snooze` and is the officially blessed waay to do this. `scheduled_at` can also be used with the replace-on-unique-conflict mechanism to ensure the delay elapses from the last request related to a resource.