Explaining technical causes and fixes for legacy links remaining accessible after image deletion

On 2026-11-07 at 13:22, Juejin published an article analyzing a peculiar failure mode: after an image is deleted, its old link remains accessible anyway. According to the piece, the lingering URL and the regeneration of already deleted material through task callbacks both trace back to a timing race between two asynchronous operations: the deletion job and the generation job. The article isolates the underlying mistake. Checking state only once at the outset is not enough to guarantee that what gets published is safe, because the image record's status can still change after that initial check has passed. A checker that reads "not deleted" at time T can therefore hand control to a generator that runs after the deletion has landed, producing a thumbnail that points at content the user explicitly removed. Stated bluntly in the original explanation, a referential guard built on a status snapshot is only as reliable as the assumption that nothing mutates underneath it, which in a system with parallel asynchronous tasks is rarely a safe assumption. The remedy the article prescribes is a structural one. It argues that the state check and the production of assets must be bound together atomically, so that a task cannot pass the check and then generate its output under a condition that has since become invalid. With the two steps fused, either the check and the generation succeed as one consistent pair or neither takes effect, and the stale link cannot be revived by a callback that finished its state verification before the deletion arrived. This piece is, so far, the only public write-up on the subject. There is no follow-up coverage in the available record describing whether the suggested fix has been adopted, and no competing explanation has surfaced to challenge the race-condition diagnosis as presented.