yonlu/yellowjacket
1
1
Fork 0
Code Issues 53 Pull Requests Actions Packages Projects Releases 13 Wiki Activity

slskd: search timeout sent in milliseconds, and finished files are found by name in a shared folder #274

New Issue
Open
opened 2026-09-27 01:58:35 +00:00 by yonlu · 1 comment
yonlu commented 2026-09-27 01:58:35 +00:00
Owner
Copy Link
Copy Source

Two defects, both found by reading slskd's source (0.26.0) against provider_slskd.go, since #267 was never run against a live daemon.

1. searchTimeout is in seconds

SearchRequest.SearchTimeout is documented as "in seconds … from the time of the last response" (default 15, minimum 5). searchRequest sends timeout.Milliseconds(), i.e. 18000, so slskd is told a search may idle for five hours. It is bounded in practice by our own poll deadline and the DELETE /searches/{id} afterwards, so the visible effect is that a search never completes on its own and always runs to our full wait.

2. collect finds files by name in a directory other grabs share

slskd moves a finished file to <downloads>/<Destination.Subdirectory>/, where the subdirectory defaults to ${SOURCE_DIRECTORY} (the remote leaf folder), and when the file already exists the default Destination.Exists = rename writes name_<ticks>.ext instead. collect looks for <downloads>/<leaf>/<name>. So:

  • a file left by an earlier failed attempt, or by the user's own download of the same folder, is collected in place of the file this grab just received (which was renamed);
  • a user who changed Destination.Subdirectory gets nothing collected at all;
  • #272's per-folder lock serialises same-named folders but cannot fix either of the above.

Direction

slskd 0.26.0 added POST /api/v0/transfers/downloads/batches, whose options.destination overrides the subdirectory pattern for that batch. Enqueue each grab as a batch with a destination unique to the grab, and collect from exactly there. On a daemon without the endpoint (404), fall back to the per-user enqueue, and in collect prefer the renamed name_<ticks>.ext written after the grab started over a pre-existing name.ext.

Add an opt-in live test (env-gated) that runs a real search and a small grab against a configured daemon, so the next API assumption is checked rather than read.

Two defects, both found by reading slskd's source (0.26.0) against `provider_slskd.go`, since #267 was never run against a live daemon. ## 1. `searchTimeout` is in seconds `SearchRequest.SearchTimeout` is documented as "in seconds … from the time of the last response" (default 15, minimum 5). `searchRequest` sends `timeout.Milliseconds()`, i.e. 18000, so slskd is told a search may idle for five hours. It is bounded in practice by our own poll deadline and the `DELETE /searches/{id}` afterwards, so the visible effect is that a search never completes on its own and always runs to our full wait. ## 2. `collect` finds files by name in a directory other grabs share slskd moves a finished file to `<downloads>/<Destination.Subdirectory>/`, where the subdirectory defaults to `${SOURCE_DIRECTORY}` (the remote leaf folder), and when the file already exists the default `Destination.Exists = rename` writes `name_<ticks>.ext` instead. `collect` looks for `<downloads>/<leaf>/<name>`. So: - a file left by an earlier failed attempt, or by the user's own download of the same folder, is collected in place of the file this grab just received (which was renamed); - a user who changed `Destination.Subdirectory` gets nothing collected at all; - #272's per-folder lock serialises same-named folders but cannot fix either of the above. ## Direction slskd 0.26.0 added `POST /api/v0/transfers/downloads/batches`, whose `options.destination` overrides the subdirectory pattern for that batch. Enqueue each grab as a batch with a destination unique to the grab, and collect from exactly there. On a daemon without the endpoint (404), fall back to the per-user enqueue, and in `collect` prefer the renamed `name_<ticks>.ext` written after the grab started over a pre-existing `name.ext`. Add an opt-in live test (env-gated) that runs a real search and a small grab against a configured daemon, so the next API assumption is checked rather than read.
yonlu self-assigned this 2026-09-27 01:58:52 +00:00
yonlu added the
Status
In Progress
 label 2026-09-27 01:58:53 +00:00
yonlu commented 2026-09-27 01:58:53 +00:00
Author
Owner
Copy Link
Copy Source

Batch branch batch/274-276-slskd with #274-#276, one PR. See the issue body for the approach.

Batch branch batch/274-276-slskd with #274-#276, one PR. See the issue body for the approach.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Downloads Kind/Bug Platform/Desktop
Priority
High
2
Reviewed
Confirmed
1
Status
In Progress
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees yonlu
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#274