`background-job:worker` ignores `--stop_after`, worker never exits

[vaenda]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

occ background-job:worker --stop_after= does not stop the worker.

Cause:
In core/Command/Background/JobWorker.php, $startTime is overwritten on every loop iteration, so after the first job has run, the check no longer measures the total runtime of the worker but the duration of the last job.
The worker therefore only exits if a single job happens to run longer than --stop_after. If evvery job in the loop has a shorter runtime, this never happens.

Code (line numbers from 34.0.3.2):
L72: $startTime = time(); // baseline for --stop_after
L96: if ($stopAfterSeconds !== null && ($startTime + $stopAfterSeconds) < time()) { break; }
L142: $startTime = microtime(true); // overwritten per job
L144: $timeSpent = microtime(true) - $startTime;

Fix:
rename the per-job variable (diff below) in L142 and L144, keep L143 as is

•   	$startTime = microtime(true);
  

•   	$jobStartTime = microtime(true);
    	$job->start($this->jobList);
  

•   	$timeSpent = microtime(true) - $startTime;
  

•   	$timeSpent = microtime(true) - $jobStartTime;
  

With that patch applied, the worker exited on its own (two separate tries with 20.97s with -t 20s and 45.82s with -t 45s, both times with exit code 0.

Origin:
Introduced in fe757f0 ("feat(jobs): allow workers to keep track of executed jobs", 2026-05-27). Before that commit, $startTime was only the --stop_after baseline.

Steps to reproduce

1. Any instance with background jobs, then occ background-job:worker -t 20s -i 1
2. Outputs "will stop after 20 seconds", processes jobs and keeps running
3. at least one job must actually run for the bug to show up. With nothing to do the bug does not show up, because the baseline is then never overwritten.

Expected behavior

the background job stops after the requested time

Nextcloud Server version

34

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "upgrade.disable-web": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": {
            "0": "cloud.example.com",
            "2": "example.org",
            "3": "www.example.org"
        },
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "34.0.3.2",
        "overwrite.cli.url": "https:\/\/cloud.example.com",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "overwriteprotocol": "https",
        "overwritehost": "cloud.example.com",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "forwarded_for_headers": [
            "HTTP_X_FORWARDED_FOR"
        ],
        "log.condition": {
            "apps": [
                "admin_audit"
            ]
        },
        "loglevel": 2,
        "maintenance": false
    }
}

List of activated Apps

Enabled:
  - activity: 7.0.0
  - admin_audit: 1.24.0
  - app_api: 34.0.0
  - appstore: 1.0.0
  - bruteforcesettings: 7.0.0
  - circles: 34.0.0
  - cloud_federation_api: 1.18.0
  - comments: 1.24.0
  - contactsinteraction: 1.15.0
  - dashboard: 7.14.0
  - dav: 1.40.0
  - federatedfilesharing: 1.24.0
  - federation: 1.24.0
  - files: 2.6.0
  - files_downloadlimit: 5.2.0
  - files_lock: 34.0.1
  - files_pdfviewer: 7.0.0-dev.0
  - files_reminders: 1.7.0
  - files_sharing: 1.26.0
  - files_trashbin: 1.24.0
  - files_versions: 1.27.0
  - firstrunwizard: 7.0.0-dev.0
  - logreader: 7.0.0
  - lookup_server_connector: 1.22.0
  - nextcloud_announcements: 6.0.0
  - notifications: 7.0.0-dev.1
  - oauth2: 1.22.0
  - office: 1.0.0
  - password_policy: 6.0.0-dev.0
  - photos: 7.0.0
  - privacy: 6.0.0-dev.1
  - profile: 1.3.0
  - provisioning_api: 1.24.0
  - recommendations: 7.0.0
  - related_resources: 5.0.0-dev.0
  - serverinfo: 6.0.0
  - settings: 1.17.0
  - sharebymail: 1.24.0
  - support: 6.0.0
  - survey_client: 6.0.0-dev.0
  - systemtags: 1.24.0
  - text: 8.0.0
  - theming: 2.9.0
  - twofactor_backupcodes: 1.23.0
  - twofactor_totp: 16.0.0
  - updatenotification: 1.24.0
  - user_status: 1.14.0
  - viewer: 7.0.0-dev.0
  - weather_status: 1.14.0
  - webhook_listeners: 1.6.0
  - workflowengine: 2.16.0
Disabled:
  - encryption: 2.22.0
  - files_external: 1.26.0
  - suspicious_login: 12.0.0-dev.0
  - twofactor_nextcloud_notification: 8.0.0
  - user_ldap: 1.25.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

Running the official nextcloud:stable Docker image (Apache variant, Debian 13,
Apache 2.4.68, PHP 8.5.9) with MariaDB 10.11.
Nothing about this depends on the container: it is a logic bug in the PHP code and the same lines are in master.

I hit the bug because a misconfigured cron had left a large backlog of queued jobs, so that this bug had a chance to show up. (I wanted to check how many jobs the worker handled in 60 seconds so i could estimate when all jobs would be done - only to find that the job did not end.

During the code analysis and measurements and collection of the facts i was assisted by AI - i understand the programming error and the fix but i have not found it myself. The Bug report has been filed by myself, a human, according to the policy.

Assisted-by: Claude:claude-opus-5.