[Enhancement] Refactoring the z_status for zim_tasks table to include DELETED flag

[Best2Two]

Why are we treating the file’s deletion status on the serverless side as detached from the database? This introduces inconsistency and adds extra logic throughout the codebase. For example, we now have conditions like isDeleted && status == 'FILE_READY'. Shouldn’t we refactor this to include a DELETED status in the database, especially if the record is going to remain in the database after it's deletion anyway?

[arybhatt4533]

Hi @Best2Two, I completely agree with this refactor. Treating the deletion status as a detached state leads to fragile logic like isDeleted && status == 'FILE_READY'.

Introducing a DELETED flag in the z_status ENUM would simplify the frontend state management and ensure the database remains the 'Single Source of Truth.' I'd be happy to help with the migration script and the corresponding backend updates to ensure the status is correctly transitioned when a file is removed.

Looking forward to your thoughts on this approach!

[audiodude]

I think that the original reason was that the deletion status of a ZIM file, which is generated and hosted entirely separately from WP1, was calculated based on a timestamp. Unlike FILE_READY, which is state transition triggered by an external webhook, there was no webhook for when the ZIM was deleted from S3-like storage (wasabi), nor was there any need to create one. ZIMs were assumed to be deleted if two weeks had passed.

As of #1090 , this flag is completely extraneous and should be removed, definitely not rolled into the implicit enum.

[arybhatt4533]

Thanks for the clarification, @audiodude. That context helps a lot.

I see now that rolling this into the enum is unnecessary since the flag itself is becoming extraneous after #1090. Instead of proceeding with the DELETED status refactor, I’ll focus on removing the extraneous flag to simplify the codebase as you suggested.