Deferred listener chunks exceed the 4000-character job argument limit of Nextcloud 32 and 33 #4651

Found during a Strict review of #4580 (development → beta promotion). Present on development; introduced in #4616.

Impact

On Nextcloud 32 and 33 (both still allowed by info.xml) every deferred chunk whose JSON is between 4,000 and 32,000 characters makes IJobList::add() throw, and the deferred work in that chunk is lost. Nextcloud 34 and later are not affected.

The chain

MAX_ARGUMENT_LENGTH = 32000 is documented as OC\BackgroundJob\JobList::MAX_ARGUMENT_JSON_LENGTH. That constant was introduced in Nextcloud 34 (server commit f01ba2de0f8, "increase length cap from 4000 to 32000"); in v32.0.0 and v33.0.0 JobList::add() throws for anything over 4000 characters. appinfo/info.xml declares <nextcloud min-version="32" max-version="35"/>, so on 32 and 33 a chunk of up to 32000 characters is still refused and the whole chunk dropped with one log line, which is the exact defect #4616 fixes. At a 4000 limit the second consequence bites too: any entry whose own JSON exceeds the limit (an update notification carrying oldData) is dropped ("only an entry that alone exceeds it is dropped") so update notifications of ordinary larger objects are lost. Introduced in #4616.

lib/Service/Deferral/ListenerDeferralService.php:82 — verified against b9e5d8df40.

Reproduction

Verified by reading the code at b9e5d8df40; not executed (no vendor tree, no rig in the review).
Verification: git -C /home/wilco/nextcloud-docker-dev/workspace/server show v33.0.0:lib/private/BackgroundJob/JobList.php | grep -n 4000; grep -n "min-version" appinfo/info.xml → strlen($argumentJson) > 4000 in v32 and v33; min-version="32"

Suggested direction

resolve the limit at runtime: \OC\BackgroundJob\JobList::MAX_ARGUMENT_JSON_LENGTH when defined, otherwise 4000; when a single entry still does not fit, enqueue it without oldData instead of dropping the notification (or name the reduction in the log).

Done when: DeferredChunksFitTheJobLimitTest runs the same entries once with a 4000 limit and once with 32000 (inject the limit through the constructor or a small resolver) and every job's JSON stays under the active limit; no entry is lost silently on the 4000 branch.

Review thread

#4580 (comment)

Fix

Proposed in #4655 (not merged yet).