Summary
Real SABnzbd has no top-level mode=priority or mode=rename. Those actions (and several others) are sub-commands of mode=queue, dispatched by the name parameter through _api_queue_table:
# sabnzbd/api.py:1133-1143 (5.1.x)
_api_queue_table = {
"delete": (_api_queue_delete, 2),
"delete_nzf": (_api_queue_delete_nzf, 2),
"rename": (_api_queue_rename, 2),
"change_complete_action": (_api_queue_change_complete_action, 2),
"purge": (_api_queue_purge, 2),
"pause": (_api_queue_pause, 2),
"resume": (_api_queue_resume, 2),
"priority": (_api_queue_priority, 2),
"sort": (_api_queue_sort, 2),
}mode=queue&name=priority&value=<nzo_id(s)>&value2=<priority> is the real endpoint a compliant client calls to change priority; mode=queue&name=rename&value=<old>&value2=<new> for rename.
What rustnzb does instead
handle_queue (crates/nzb-web/src/sabnzbd_compat.rs) only special-cases name ∈ {"delete", "pause", "resume"}. Any other name (priority, rename, purge, sort, change_complete_action, delete_nzf) silently falls through to the default branch and returns a plain queue listing instead of performing the action or returning {"status": ...}.
Meanwhile, rustnzb does implement mode=priority and mode=rename as fabricated top-level modes — these don't exist in the real SABnzbd protocol (they're absent from _api_table, api.py:1078-1131), so no compliant client would ever call them.
Impact
No real SABnzbd-protocol client (Sonarr, Radarr, NZB360, the reference SABnzbd web UI, etc.) can successfully change a job's priority or rename it against rustnzb, because the endpoint they actually call is a silent no-op.
Fix
Route mode=queue&name=X sub-commands (at minimum priority, rename; ideally also purge, sort, delete_nzf, change_complete_action) to the existing handler logic, matching _api_queue_priority's value/value2 contract (value = comma-separated nzo_ids, value2 = priority). The existing top-level mode=priority/mode=rename can stay as a compatibility bonus but shouldn't be the only path.
Summary
Real SABnzbd has no top-level
mode=priorityormode=rename. Those actions (and several others) are sub-commands ofmode=queue, dispatched by thenameparameter through_api_queue_table:mode=queue&name=priority&value=<nzo_id(s)>&value2=<priority>is the real endpoint a compliant client calls to change priority;mode=queue&name=rename&value=<old>&value2=<new>for rename.What rustnzb does instead
handle_queue(crates/nzb-web/src/sabnzbd_compat.rs) only special-casesname ∈ {"delete", "pause", "resume"}. Any othername(priority,rename,purge,sort,change_complete_action,delete_nzf) silently falls through to the default branch and returns a plain queue listing instead of performing the action or returning{"status": ...}.Meanwhile, rustnzb does implement
mode=priorityandmode=renameas fabricated top-level modes — these don't exist in the real SABnzbd protocol (they're absent from_api_table,api.py:1078-1131), so no compliant client would ever call them.Impact
No real SABnzbd-protocol client (Sonarr, Radarr, NZB360, the reference SABnzbd web UI, etc.) can successfully change a job's priority or rename it against rustnzb, because the endpoint they actually call is a silent no-op.
Fix
Route
mode=queue&name=Xsub-commands (at minimumpriority,rename; ideally alsopurge,sort,delete_nzf,change_complete_action) to the existing handler logic, matching_api_queue_priority'svalue/value2contract (value= comma-separated nzo_ids,value2= priority). The existing top-levelmode=priority/mode=renamecan stay as a compatibility bonus but shouldn't be the only path.