mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-13 11:23:39 +02:00
DarkBreakpoint
22379238ea
Two users asking for the same film produced two downloads of the same bytes. Deduplication was scoped to the requester on purpose: with a single physical file per request, telling the second user "duplicate" would have left them with nothing. The split made one file reachable from several library entries, so that constraint is gone -- but promotion still took the head of the queue unconditionally. Two entries on one file would each have been promoted and each run a transfer to the same path: two writers, one file. Promotion is now materialization-aware. Before an entry runs, `promotion_decision` asks what else holds its media: Execute nothing does -- transfer it AttachTo another entry already finished it -- adopt the file Wait another entry is producing it -- do not open a second writer `attach_to_completed` copies only the physical result. The owner, visibility and quota stay with the entry: this is one user's link onto a file another user's request happened to produce. With that in place `candidate_has_duplicate_recording` narrows from "anyone already asked for this" to "this quota pool already asked for this", and `RecordingIdentity` drops its owner and visibility fields -- the same URL over the same window is the same bytes, whoever asked. An empty media identity deliberately matches nothing, not even another empty one. It means the identity could not be resolved, and treating two unidentified requests as one recording would merge two different files. Not changed: quota is still charged per entry against the full size, so a shared file is counted once per attached entry rather than once physically. That is the next step.