A refused XMLRPC size limit blanks the whole settings probe on rTorrent 0.16.22

[noctuum]

Please complete the following tasks.

• Web browser cache cleared
• Link provided to install script if applicable
• Not using broken rtinst install script
• Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Web Browser: Google Chrome Version 153.0.8010.12 (Official Build) beta (x86_64)
ruTorrent: v5.3.13
PHP: PHP 8.4.21 (cli) (built: May 7 2026 16:01:59) (NTS)
OS: Alpine Linux v3.23.5
rTorrent: 0.16.22

Tell us how you installed ruTorrent

This Docker image: https://github.com/crazy-max/docker-rtorrent-rutorrent

Describe the bug

On a fresh load against rTorrent 0.16.22, the status bar reads rTorrent: 0.16.22/ with the libTorrent half empty, ruTorrent reports it cannot determine the UID of the rTorrent user, the listening port shown is the daemon default instead of the configured one, and autotools, xmpp and rutracker_check disable themselves reporting an empty session path — literally (), nothing between the parentheses.

Four symptoms, one cause: the settings probe sends set_xmlrpc_size_limit as one of eight commands in a single batched request, and every other reading in that batch — plus the branch that resolves uid/gid/home — is assigned only inside the success check that follows. rTorrent 0.16.22 refuses the value ruTorrent asks for, the batch faults, and all of it is left unset together.

Steps to reproduce

1. Run ruTorrent against rTorrent 0.16.22 or later (any daemon built after rakshasa/rtorrent#1957).
2. Load the web UI.
3. See the empty libTorrent version, the UID warning, the wrong port, and the three plugins disabled with an empty session path.

Expected behavior

A refused size-limit write should not affect any of the other seven readings in the probe, or the uid/gid/home resolution that follows them.

Additional context

The batch:

ruTorrent/php/settings.php

Lines 283 to 302 in cd814cb

	$req = new rXMLRPCRequest( array(
	new rXMLRPCCommand("get_directory"),
	new rXMLRPCCommand("get_session"),
	new rXMLRPCCommand("system.library_version"),
	new rXMLRPCCommand("set_xmlrpc_size_limit",67108863),
	new rXMLRPCCommand("get_name"),
	new rXMLRPCCommand("get_port_range"),
	new rXMLRPCCommand("get_bind"),
	new rXMLRPCCommand("get_ip"),
	) );
	if($req->success())
	{
	$this->directory = $req->val[0];
	$this->session = $req->val[1];
	$this->libVersion = $req->val[2];
	$this->server = $req->val[4];
	$this->portRange = $req->val[5];
	$this->port = intval($this->portRange);
	$this->bind = $req->val[6];
	$this->ip = $req->val[7];

success() is run() && !fault, so one faulted command skips every assignment in the block — including directory, session, libVersion, server, portRange, port, bind, ip, and, nested further in, uid, gid, home.

rakshasa/rtorrent#1957, merged into 0.16.22, moved the size-limit ceiling into RpcManager::set_size_limit and tests it against SCgiTask::max_content_size:

void
RpcManager::set_size_limit(uint64_t size) {
  if (size > SCgiTask::max_content_size)
    throw torrent::input_error("XMLRPC size limit cannot exceed the SCGI content size limit.");

  m_xmlrpc.set_size_limit(size);
}

static constexpr int max_content_size    = (2 << 23);   // 16777216

The value ruTorrent sends, 67108863, is (64 << 20) - 1 — sized against the old pre-0.16.22 ceiling, which the PR itself notes "was unrelated to what actually bounds a request" and wasn't enforced at all under the tinyxml2 backend. 67108863 > 16777216, so the call now fails on every installation regardless of the daemon's own configured limit.

Measured directly against a 0.16.22 daemon over its SCGI endpoint:

value sent	result
67108863 — what ruTorrent sends	fault -500, XMLRPC size limit cannot exceed the SCGI content size limit.
16777216 — SCgiTask::max_content_size	accepted
16777217 — one above	fault -500, same message

rakshasa/rtorrent#1968 has the daemon-side ceiling acknowledged, with the maintainer noting on 2026-09-04 it should become a single configurable setting. That's the daemon side; this report is about the probe treating a refused write as fatal to seven unrelated readings, which is worth fixing whatever ceiling rTorrent eventually settles on.

I have a fix — move the size-limit command into its own request, the way this file already handles system.api_version and network.listen.port when they may fail — and will open a PR referencing this issue.