[bug] Attachments disappearing with delete and redraft #775
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#775
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Your setup
From source
Extra details
Ubuntu 23.04
Version
c02e3432d9
PostgreSQL version
15
What were you trying to do?
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.
LogsAdditional informationUpload filters are Exiftool.StripMetadata and Dedupe.
Severity
I cannot use it as easily as I'd like
Have you searched for this issue?
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 behaviourig (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 assnooze
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.Oneric referenced this issue2024-06-03 22:28:25 +00:00