plundrio/internal/server/ at main · else42.tngl.sh/plundrio · Tangled

else42.tngl.sh / plundrio

0

[READ-ONLY] Mirror of https://github.com/elsbrock/plundrio. 🏴‍☠️ put.io download client for *arr implementing the transmission RPC interface

bazarr putio radarr readarr sonarr transmission-rpc whisparr

0

plundrio / internal / server /

at main 9 files

Simon Elsbrock fix(transfers): check errors the linter flagged, fixing a silent no-op 14d ago

fix(transfers): check errors the linter flagged, fixing a silent no-op golangci-lint reported 8 unchecked errors and one style issue, all pre-existing. One of them was hiding a real defect: processTransfer called FailTransfer before initializeTransfer, so for a transfer that reports no files the call returned TransferNotFound and did nothing. The transfer stayed untracked and was therefore re-examined on every 30s poll forever. It is now initialised first and genuinely recorded as Failed, which puts it on the bounded-retry path. The rest are mechanical: check or explicitly discard the remaining errors, and use a tagged switch on r.Method. golangci-lint now reports 0 issues.

2 weeks ago

refactor: propagate context, encapsulate state, extract interfaces Propagate context.Context through api.Client: - Remove stored ctx field from api.Client; accept context per-call - Thread request context from HTTP handlers through to put.io calls - Use manager lifecycle context for background operations Encapsulate TransferContext mutable state: - Unexport mutable fields (completedFiles, downloadedSize, state, etc.) - Add thread-safe accessor methods (GetProgress, GetState, AddDownloadedBytes, etc.) - Replace atomic ops + mutex with plain increments under mutex - Remove verbose debug logging from GetTransferContext Decouple TransferCoordinator from Manager: - Replace *Manager field with onProcessed callback function - Add RangeTransfers method to avoid exposing sync.Map internally Extract consumer-defined PutioClient interfaces: - download.PutioClient (6 methods) in manager.go - server.PutioClient (6 methods) in server.go - Rename dlManager → dlService, accept DownloadService interface - Use atomic.Bool for quotaWarning flag Extract progress calculation: - Move 130-line inline progress block from handleTorrentGet into calculateProgress() in new progress.go with pure-function design - Extract mapPutioStatusValue() from server method to package function - Define Transmission status constants Fix startup race in monitorTransfers: - Remove redundant newTransferProcessor() that overwrote m.processor without synchronization; processor is already created in New() Fix double-counting of downloaded bytes: - Progress ticker already accumulates full file size via deltas - Completion handler was adding totalSize again (2x actual) - Now flushes only the delta between last tick and final size

5 months ago

progress_test.go

test: add coordinator, progress, and download tests - coordinator_test.go: state machine coverage (happy path, invalid transitions, idempotent FileCompleted, cleanup hooks, cancel vs fail) - progress_test.go: table-driven tests for calculateProgress (all status paths, with/without TransferContext, zero-size fallback) - download_test.go: isTransientError coverage including known limitation with wrapped errors - torrent_test.go: fix formatting

5 months ago

chore: improve logging

1 year ago

fix(download): retry transfers whose local download failed Nothing ever removed a TransferContext from the coordinator, and the 'already being processed' check treated any tracked transfer as in flight. One permanent file failure therefore stranded the transfer forever: never retried, put.io source never cleaned up, never reported complete to *arr — despite three log lines claiming it was being kept for retry. shouldProcess now drops a failed transfer's context so the next poll sees it as new, bounded by maxReprocessAttempts (mirroring the existing retry idiom for errored put.io transfers) and deferred until the transfer has settled, so a retry cannot queue a second generation of files still in flight. torrent-remove now also drops the coordinator context and retry counters, which is what keeps that tracking state from growing for the process lifetime. Processed contexts still survive until then, since *arr queries them as 100% complete until it removes the torrent. Also removes the Server.Stop -> dlService.Stop layering inversion (main owns that lifecycle and now stops the server first, then drains downloads), the no-op net/http/pprof import, and a duplicated active-file counting loop.

2 weeks ago

fix(download): retry transfers whose local download failed Nothing ever removed a TransferContext from the coordinator, and the 'already being processed' check treated any tracked transfer as in flight. One permanent file failure therefore stranded the transfer forever: never retried, put.io source never cleaned up, never reported complete to *arr — despite three log lines claiming it was being kept for retry. shouldProcess now drops a failed transfer's context so the next poll sees it as new, bounded by maxReprocessAttempts (mirroring the existing retry idiom for errored put.io transfers) and deferred until the transfer has settled, so a retry cannot queue a second generation of files still in flight. torrent-remove now also drops the coordinator context and retry counters, which is what keeps that tracking state from growing for the process lifetime. Processed contexts still survive until then, since *arr queries them as 100% complete until it removes the torrent. Also removes the Server.Stop -> dlService.Stop layering inversion (main owns that lifecycle and now stops the server first, then drains downloads), the no-op net/http/pprof import, and a duplicated active-file counting loop.

2 weeks ago

torrent_add_test.go

fix(download): retry transfers whose local download failed Nothing ever removed a TransferContext from the coordinator, and the 'already being processed' check treated any tracked transfer as in flight. One permanent file failure therefore stranded the transfer forever: never retried, put.io source never cleaned up, never reported complete to *arr — despite three log lines claiming it was being kept for retry. shouldProcess now drops a failed transfer's context so the next poll sees it as new, bounded by maxReprocessAttempts (mirroring the existing retry idiom for errored put.io transfers) and deferred until the transfer has settled, so a retry cannot queue a second generation of files still in flight. torrent-remove now also drops the coordinator context and retry counters, which is what keeps that tracking state from growing for the process lifetime. Processed contexts still survive until then, since *arr queries them as 100% complete until it removes the torrent. Also removes the Server.Stop -> dlService.Stop layering inversion (main owns that lifecycle and now stops the server first, then drains downloads), the no-op net/http/pprof import, and a duplicated active-file counting loop.

2 weeks ago

torrent_test.go

fix(download): retry transfers whose local download failed Nothing ever removed a TransferContext from the coordinator, and the 'already being processed' check treated any tracked transfer as in flight. One permanent file failure therefore stranded the transfer forever: never retried, put.io source never cleaned up, never reported complete to *arr — despite three log lines claiming it was being kept for retry. shouldProcess now drops a failed transfer's context so the next poll sees it as new, bounded by maxReprocessAttempts (mirroring the existing retry idiom for errored put.io transfers) and deferred until the transfer has settled, so a retry cannot queue a second generation of files still in flight. torrent-remove now also drops the coordinator context and retry counters, which is what keeps that tracking state from growing for the process lifetime. Processed contexts still survive until then, since *arr queries them as 100% complete until it removes the torrent. Also removes the Server.Stop -> dlService.Stop layering inversion (main owns that lifecycle and now stops the server first, then drains downloads), the no-op net/http/pprof import, and a duplicated active-file counting loop.

2 weeks ago

refactor: propagate context, encapsulate state, extract interfaces Propagate context.Context through api.Client: - Remove stored ctx field from api.Client; accept context per-call - Thread request context from HTTP handlers through to put.io calls - Use manager lifecycle context for background operations Encapsulate TransferContext mutable state: - Unexport mutable fields (completedFiles, downloadedSize, state, etc.) - Add thread-safe accessor methods (GetProgress, GetState, AddDownloadedBytes, etc.) - Replace atomic ops + mutex with plain increments under mutex - Remove verbose debug logging from GetTransferContext Decouple TransferCoordinator from Manager: - Replace *Manager field with onProcessed callback function - Add RangeTransfers method to avoid exposing sync.Map internally Extract consumer-defined PutioClient interfaces: - download.PutioClient (6 methods) in manager.go - server.PutioClient (6 methods) in server.go - Rename dlManager → dlService, accept DownloadService interface - Use atomic.Bool for quotaWarning flag Extract progress calculation: - Move 130-line inline progress block from handleTorrentGet into calculateProgress() in new progress.go with pure-function design - Extract mapPutioStatusValue() from server method to package function - Define Transmission status constants Fix startup race in monitorTransfers: - Remove redundant newTransferProcessor() that overwrote m.processor without synchronization; processor is already created in New() Fix double-counting of downloaded bytes: - Progress ticker already accumulates full file size via deltas - Completion handler was adding totalSize again (2x actual) - Now flushes only the delta between last tick and final size

5 months ago