Bug Report: HTTP 429 Too Many Requests When Scheduling Tasks in Nextcloud Task Processing API

Nextcloud version: 35.0.2.2
Context Agent version: 2.11.0
Affected component: Task Processing API / Context Agent
Environment: Nextcloud running in Docker behind Traefik
Severity: Medium – AI requests intermittently fail during processing.

1. Problem Description

When using Nextcloud Chat with AI, the Context Agent intermittently failed to schedule tasks through the Nextcloud Task Processing API.

The Context Agent logs showed the following error:

niquests.exceptions.HTTPError:
429 Client Error: Too Many Requests

POST https://my.domain.ltd/ocs/v1.php/taskprocessing/schedule?format=json

nc_py_api._exceptions.NextcloudException:
[429] Too Many Requests

The error was generated by the Context Agent while attempting to schedule a task.

The issue occurred repeatedly during AI request processing and prevented the expected response from being returned.

2. Environment and Diagnostic Findings

The following environment was verified:

  • Nextcloud 35.0.2.2

  • Context Agent 2.11.0

  • Context Chat and Context Chat Backend installed

  • Nextcloud deployed using Docker

  • Traefik used as reverse proxy

The following checks were performed:

  • Checked Traefik configuration for rate-limit middleware.

  • Checked Traefik logs for HTTP 429 errors.

  • Inspected the Nextcloud system configuration.

  • Checked Task Processing worker processes and task statistics.

  • Inspected the Nextcloud Task Processing API controller source code.

No evidence of a Traefik rate-limit middleware was found.

Some Context Agent tasks were successfully processed by the Task Processing worker, indicating that the worker was operational.

3. Root Cause

Inspection of the following Nextcloud source file:

core/Controller/TaskProcessingApiController.php

revealed the following rate-limit annotation on the standard task scheduling endpoint:

#[UserRateLimit(limit: 20, period: 120)]

This configures a limit of 20 requests per 120 seconds.

The affected endpoint was:

POST /ocs/v1.php/taskprocessing/schedule

The Context Agent generated enough scheduling requests to exceed this limit, resulting in HTTP 429 responses.

This rate limit appears insufficient for the request pattern generated by the Context Agent during AI processing.

4. Applied Workaround / Fix

The rate limit was increased from 20 to 100 requests per 120 seconds.

Original code:

#[UserRateLimit(limit: 20, period: 120)]

Modified code:

#[UserRateLimit(limit: 100, period: 120)]

The Nextcloud container was restarted after the modification.

5. Result

After increasing the rate limit and restarting the Nextcloud container:

  • Chat with AI started returning responses successfully.

  • The previously observed HTTP 429 error was no longer preventing AI requests from completing.

  • The workaround resolved the reported problem in this environment.

Important: The current workaround modifies a Nextcloud Core source file directly. This modification may be overwritten by future Nextcloud updates. A supported configuration option or an upstream code change would be preferable.

7. Conclusion

The problem was traced to the rate limit configured on the Nextcloud Task Processing API scheduling endpoint.

Increasing the limit from 20 to 100 requests per 120 seconds resolved the issue in the tested environment.

The recommended permanent solution is to make the rate limit configurable or adjust the default limit to accommodate the scheduling requirements of Context Agent and other AI applications.

Thank you for investigating this issue.

@tonivet welcome to the Nextcloud community :waving_hand:

please consider posting your bug report on the developers GitHub:

https://github.com/nextcloud/tasks

Small note: since the rate limit is defined in core/Controller/TaskProcessingApiController.php, I think this belongs in the nextcloud/server repository rather than nextcloud/tasks. The latter is the calendar Tasks app.

Also, increasing the limit fixes the immediate problem, but I wonder if the Context Agent should handle 429 responses more gracefully instead of failing the whole request. Some sort of backoff and retry would help when several tasks are scheduled close together.

The limit is there for a reason, so making it configurable might be a better long-term option than just raising it for everyone.