Skip to content

Fix DirectUnpack finalization after PAR failure - #869

Open
xbmc4lyfe wants to merge 4 commits into
nzbgetcom:developfrom
xbmc4lyfe:codex/fix-748-directunpack-status
Open

Fix DirectUnpack finalization after PAR failure#869
xbmc4lyfe wants to merge 4 commits into
nzbgetcom:developfrom
xbmc4lyfe:codex/fix-748-directunpack-status

Conversation

@xbmc4lyfe

Copy link
Copy Markdown
Contributor

Summary

  • allow successful DirectUnpack jobs to finish normal unpack finalization even when forced PAR checking fails
  • preserve the PAR failure and existing skip behavior when direct unpack did not run or failed
  • add lifecycle regression coverage proving extracted files are promoted and unpack status becomes successful

Verification

  • Linux real-Unrar lifecycle regression
  • Linux PostprocessTest, 38 test cases
  • macOS full CTest suite, 10/10
  • git diff --check

Fixes #748

Allow successful direct unpack jobs to complete normal unpack finalization even when a forced PAR check fails. Preserve the existing PAR failure status and skip behavior for direct unpack jobs that did not succeed.

Fixes nzbgetcom#748
@xbmc4lyfe
xbmc4lyfe force-pushed the codex/fix-748-directunpack-status branch from ec3cdb5 to 20aeddc Compare July 19, 2026 16:26
@dnzbk
dnzbk self-requested a review July 21, 2026 16:03
Comment thread tests/postprocess/DirectUnpack.cpp
@dnzbk

dnzbk commented Jul 21, 2026

Copy link
Copy Markdown
Collaborator

@xbmc4lyfe Could you update POST-PROCESSING.md to clarify that NZBPP_UNPACKSTATUS=2 can coexist with NZBPP_PARSTATUS=1 when DirectUnpack is enabled?

…ctunpack-status

# Conflicts:
#	tests/postprocess/DirectUnpack.cpp
Extract MakeParFailureTestOpts()/QueueParFailureTestNzb() so the two
new tests share cmdopts/NzbInfo setup instead of duplicating it, per
review feedback that the added test code was heavy for a 1-line fix.

The full-lifecycle test still drives the real async pipeline: StartJob
is private and only reachable through PrePostProcessor's real Run()
loop, and UnpackController::CheckArchiveFiles() decides whether to
reuse already-extracted files based on bookkeeping only a real
DirectUnpack pass populates, so a narrower unit-level test of the
condition alone isn't achievable without refactoring production code
beyond this fix's scope.
Clarify in POST-PROCESSING.md that when DirectUnpack already extracted
a download successfully, unpack still finalizes (UNPACKSTATUS=2) even
if the par-check that runs afterward fails (PARSTATUS=1), and that the
overall NZBPP_STATUS still reflects the par failure.
@xbmc4lyfe

Copy link
Copy Markdown
Contributor Author

@dnzbk Done in 12fba7a — added a note under NZBPP_UNPACKSTATUS in POST-PROCESSING.md clarifying that NZBPP_UNPACKSTATUS=2 (unpack successful) can be reported together with NZBPP_PARSTATUS=1 (checked and failed to repair) when DirectUnpack already extracted the download successfully, and that NZBPP_STATUS/NZBPP_TOTALSTATUS still reflect the par failure in that case (e.g. FAILURE/PAR).

(A prior reply to this comment appears to have gone missing — reposting to make sure this lands.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect NZBPP_UNPACKSTATUS / NZBPP_STATUS

2 participants