Skip to content

Fix batch rate-limit scheduling for partial batches - #2132

Open
hugosmoreira wants to merge 1 commit into
weaviate:mainfrom
hugosmoreira:feature/1100-batch-rate-limit
Open

Fix batch rate-limit scheduling for partial batches#2132
hugosmoreira wants to merge 1 commit into
weaviate:mainfrom
hugosmoreira:feature/1100-batch-rate-limit

Conversation

@hugosmoreira

Copy link
Copy Markdown

Summary

  • calculate rate-limit spacing from the number of objects actually sent in the previous batch
  • record the timestamp when a rate-limited batch is dispatched, after the scheduler finishes filling it
  • preserve future timestamps set by concurrent rate-limit retries
  • add focused coverage for full, partial, elapsed, retry-backoff, and empty batches

Root cause

Rate-limited batching used a fixed interval derived from the configured concurrency. A partial batch therefore incurred the same delay as a full batch, which unnecessarily reduced throughput. The request timestamp was also recorded before the scheduler's batch-filling wait.

The new interval is proportional to the previous batch's actual object count:

base_time * objects_sent / requests_per_minute

Full batches retain their existing spacing, while partial batches can proceed sooner without exceeding the configured object rate.

Validation

  • pytest test/collection/test_batch.py -q — 16 passed
  • pytest test --ignore=test/test_timeout.py -q — 414 passed, 1 skipped
  • pytest mock_tests -q — 56 passed
  • ruff check weaviate test mock_tests integration — passed
  • ruff format --check weaviate test mock_tests integration — passed
  • flake8 weaviate test mock_tests integration — passed
  • pyright weaviate/collections/batch/base.py — passed
  • package build and twine check — passed
  • pytest integration/test_batch_v4.py::test_add_objects_in_multiple_batches -vv against Weaviate 1.39.0 — passed
  • live two-partial-batch probe against Weaviate 1.39.0 — 2 objects imported; second batch completed in 1.187 seconds instead of the previous approximately 62-second delay
  • remaining default-server batch integration coverage — 63 passed, 3 skipped

Two async-indexing integration cases could not run locally because Windows reserves the repository's configured host port 50061. Two unrelated subprocess timeout-harness tests were excluded locally because Windows xdist termination does not forward their expected stderr text; the remaining unit suite passed.

Fixes #1100

Calculate the next batch delay from the number of objects actually sent, preserve retry backoff timestamps, and cover full, partial, elapsed, retry, and empty-batch cases.

@orca-security-eu orca-security-eu Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Orca Security Scan Summary

Status Check Issues by priority
Passed Passed Infrastructure as Code high 0   medium 0   low 0   info 0 View in Orca
Passed Passed SAST high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Secrets high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Vulnerabilities high 0   medium 0   low 0   info 0 View in Orca

@weaviate-git-bot

Copy link
Copy Markdown

To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Forum?

@hugosmoreira

Copy link
Copy Markdown
Author

I have read and agree to the Weaviate Contributor License Agreement.

@hugosmoreira
hugosmoreira marked this pull request as ready for review August 12, 2026 05:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improve batch rate limiting logic

2 participants