Possible regression in RAR file handling in 1.1.6 -> 2.0

[gamdud]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Current Behavior

In 2.0, my RD-backed rar links are not getting virtually unrar'ed and served, except the first one. And I think the one it serves is broken.

Expected Behavior

In 1.1.6 'Unpack RAR' + internal webdav + internal rclone + decypharr would create symlinks for stuff that was actually backed by a rar file.

Steps To Reproduce

So a magnet link, example https://pastebin.com/raw/cmpGJm1d would become four files that were servable.

Environment

- OS: linux
- Version: 2.0 
- Docker Install: yea 
- Browser: chrome

What branch are you running?

Main/Latest

Trace Logs? Not Optional

Here's me trying it twice:

+-------------------------------------------------------+
|                                                       |
|  ╔╦╗╔═╗╔═╗╦ ╦╔═╗╦ ╦╔═╗╦═╗╦═╗                          |
|   ║║║╣ ║  └┬┘╠═╝╠═╣╠═╣╠╦╝╠╦╝ (2.0-stable)        |
|  ═╩╝╚═╝╚═╝ ┴ ╩  ╩ ╩╩ ╩╩╚═╩╚═                          |
|                                                       |
+-------------------------------------------------------+
|  Log Level: trace                                        |
+-------------------------------------------------------+
2026-04-12 10:40:23 | INFO  | [http] Starting server on 0.0.0.0:8282/
2026-04-12 10:40:23 | INFO  | [manager] Starting manager mount_path=/mnt/decypharr/dfs mount_type=dfs notifications=false version=2.0-stable
2026-04-12 10:40:23 | INFO  | [dfs] Starting DFS with backend backend=hanwen mount_path=/mnt/decypharr/dfs
2026-04-12 10:40:23 | INFO  | [manager] Performing initial sync of torrents from debrid clients... debrids=1
2026-04-12 10:40:23 | INFO  | [hanwen-backend] Waiting for mount to be ready mount_path=/mnt/decypharr/dfs
2026-04-12 10:40:23 | INFO  | [dfs] DFS started successfully backend=hanwen mount_path=/mnt/decypharr/dfs
2026-04-12 10:40:24 | INFO  | [manager] Initial sync of torrents from debrid clients completed
2026-04-12 10:40:33 | INFO  | [realdebrid] Torrent: XQS7RS4QCKLHK deleted from RD
2026-04-12 10:41:05 | INFO  | [realdebrid] Processing torrent Action=symlink Arr=abb Hash=7dc9b203a9fb4dcf2aa3760ab9f64eec2d8d5a7e Name= Provider=realdebrid
2026-04-12 10:41:05 | INFO  | [realdebrid] Entry:  submitted to realdebrid id=UTC464YQVNWNW
2026-04-12 10:41:06 | INFO  | [realdebrid] RAR file detected, unpacking: Ada Palmer - Terra Ignota (2016–2021)
2026-04-12 10:41:07 | INFO  | [realdebrid] Unpacked RAR archive for torrent: Ada Palmer - Terra Ignota (2016–2021) with 1 files
2026-04-12 10:41:07 | INFO  | [realdebrid] Torrent: Ada Palmer - Terra Ignota (2016–2021) downloaded to RD
2026-04-12 10:41:07 | INFO  | [manager] Download completed, processing action action=symlink name="Ada Palmer - Terra Ignota (2016–2021)"
2026-04-12 10:41:07 | INFO  | [manager] Creating symlinks for 1 files in /mnt/decypharr/completed/abb/Ada Palmer - Terra Ignota (2016–2021) component=downloader mount_path="/mnt/decypharr/dfs/__all__/Ada Palmer - Terra Ignota (2016–2021)"
2026-04-12 10:41:07 | INFO  | [manager] File is ready: Ada Palmer - Terra Ignota (2016–2021)/Too Like the Lightning (2016) [Terra Ignota 1].m4b component=downloader
2026-04-12 10:41:42 | INFO  | [realdebrid] Torrent: UTC464YQVNWNW deleted from RD
2026-04-12 10:44:29 | INFO  | [realdebrid] Processing torrent Action=symlink Arr=abb Hash=7dc9b203a9fb4dcf2aa3760ab9f64eec2d8d5a7e Name= Provider=realdebrid
2026-04-12 10:44:30 | INFO  | [realdebrid] Entry:  submitted to realdebrid id=KJYEMEN3TZJSC
2026-04-12 10:44:30 | INFO  | [realdebrid] RAR file detected, unpacking: Ada Palmer - Terra Ignota (2016–2021)
2026-04-12 10:44:31 | INFO  | [realdebrid] Unpacked RAR archive for torrent: Ada Palmer - Terra Ignota (2016–2021) with 1 files
2026-04-12 10:44:31 | INFO  | [realdebrid] Torrent: Ada Palmer - Terra Ignota (2016–2021) downloaded to RD
2026-04-12 10:44:31 | INFO  | [manager] Download completed, processing action action=symlink name="Ada Palmer - Terra Ignota (2016–2021)"
2026-04-12 10:44:31 | INFO  | [manager] Creating symlinks for 1 files in /mnt/decypharr/completed/abb/Ada Palmer - Terra Ignota (2016–2021) component=downloader mount_path="/mnt/decypharr/dfs/__all__/Ada Palmer - Terra Ignota (2016–2021)"
2026-04-12 10:44:32 | INFO  | [manager] File is ready: Ada Palmer - Terra Ignota (2016–2021)/Too Like the Lightning (2016) [Terra Ignota 1].m4b component=downloader

Trace Logs have been provided as applicable

• I have read and followed the steps in the documentation link and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

[Thoroslives]

Still seeing this on v2.1 (image digest 9a386f572584b, 2026-04-15 release). The RAR reader fix in 5cc9a78 is in place, but there's a separate issue that looks like a race between the download path and an internal sync loop re-reading the same entry.

Test case: a Sonarr-submitted release that RD bundled into a RAR archive. bbolt db was freshly wiped immediately before the test, so no v2.0 migration residue.

11:54:42  Processing torrent Action=download Arr=sonarr Provider=realdebrid
11:54:42  Entry submitted to realdebrid id=U4KYD7ZXHGRSW
11:54:43  Started downloading torrent
11:59:24  RAR file detected, unpacking
11:59:32  Unpacked RAR archive with 2 files
11:59:32  Torrent downloaded to RD
11:59:32  Download completed, processing action
11:59:32  Downloading 2 files...
11:59:35  RAR file detected, unpacking    <-- fires again on same entry
11:59:38  RAR file detected, unpacking    <-- again
11:59:41  Unpacked RAR archive with 2 files
11:59:41  Torrent downloaded to RD
11:59:41  Successfully re-inserted entry  infohash=<hash>
11:59:42  Torrent: U4KYD7ZXHGRSW deleted from RD
11:59:45  Unpacked RAR archive with 2 files
11:59:45  Download completed, processing action
11:59:54  ERROR checking status: realdebrid API error: Status: 404

The re-unpack at 11:59:35 isn't triggered by the arr or RD, which suggests Decypharr's own sync loop is re-reading the entry while the download is still active. The re-insert at 11:59:41 then triggers deletion of the original RD torrent (U4KYD7ZXHGRSW), and subsequent status polls 404 because the RD entry is gone.

A non-RAR torrent for the same episode submitted 15 minutes earlier completed in 38s with a single clean status=206 transfer. Earlier the same day, a smaller RAR torrent completed in 28s, fast enough that the sync loop probably didn't hit it mid-unpack. The failing torrent took ~5 minutes from start to first unpack, which seems long enough to race.

Looks like the sync/queue logic needs to treat an in-flight entry as non-syncable until the downloader releases it.

Happy to send full trace logs if useful.