Fix BatchLogRecordProcessor default schedule_delay_millis to 1000ms per OTel spec by Manvi2402 · Pull Request #4998 · open-telemetry/opentelemetry-python

Manvi2402 · 2026-03-18T15:18:23Z

…er OTel spec

Description

The BatchLogRecordProcessor._DEFAULT_SCHEDULE_DELAY_MILLIS was set to
5000ms, but the OTel specification defines OTEL_BLRP_SCHEDULE_DELAY
default as 1000ms.

Fixes #4991

Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Updated existing unit tests in opentelemetry-sdk/tests/logs/test_export.py
to reflect the corrected default value of 1000ms instead of 5000ms.

Does This PR Require a Contrib Repo Change?

Yes. - Link to PR:
[ x ] No.

Checklist:

[ x ] Followed the style guidelines of this project
[ x ] Changelogs have been updated
[ x ] Unit tests have been added
[ x ] Documentation has been updated

…er OTel spec

pmcollins

Thanks for the change. Can you also update the default value in the docstring for OTEL_BLRP_SCHEDULE_DELAY (in environment_variables/__init__.py)?

…HANGELOG

Manvi2402 · 2026-03-19T06:08:22Z

Hi @pmcollins , I've made both the requested changes — updated the CHANGELOG wording and the OTEL_BLRP_SCHEDULE_DELAY docstring default to 1000ms. Please let me know if anything else is needed!

themavik

Summary: Aligns BatchLogRecordProcessor default schedule_delay_millis from 5000ms to 1000ms per OTel spec.

Done well: Changelog clearly documents the 5x export frequency change for users who rely on defaults. All three touchpoints updated consistently: _DEFAULT_SCHEDULE_DELAY_MILLIS, env var docs, and the three test_args_* assertions (5→1 seconds). The test values correctly reflect seconds internally.

Note: Users not setting OTEL_BLRP_SCHEDULE_DELAY will see more frequent exports; the changelog handles this. Consider whether any performance or rate-limit docs should mention the new default.

Manvi2402 · 2026-03-19T12:33:45Z

Thank you for the detailed review @themavik . Agreed on the performance/rate-limit docs — that feels like a separate issue. Happy to open one if that would be helpful!

…ub.com/Manvi2402/opentelemetry-python into fix/batch-log-processor-schedule-delay

@xrmx

…er OTel spec (open-telemetry#4998) * Fix BatchLogRecordProcessor default schedule_delay_millis to 1000ms per OTel spec * Update OTEL_BLRP_SCHEDULE_DELAY docstring default to 1000ms and fix CHANGELOG * Apply suggestion from @xrmx * Update CHANGELOG wording to 'may be' for export frequency * Apply suggestion from @xrmx --------- Co-authored-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>

The SDK's increment_hit_count uses `hit_count > config.max_hits` for the disable check (instrumentation_manager.py:631), so MaxHits=N emits N snapshots and disables on the (N+1)th hit. The DI Flask and FastAPI hit-limit contract tests expected N-1 snapshots, claiming the check was `>=` in both their docstrings and inline comments — neither matched the SDK. The tests were passing on main by accident: BatchLogRecordProcessor's default schedule_delay_millis was 5000ms, so the snapshot emitted on the 3rd hit was still sitting in the batch buffer when the test's 2-second sleep elapsed and read the collector. core 1.41.0 tightened the default to 1000ms (open-telemetry/opentelemetry-python#4998), shrinking the window enough that the 3rd snapshot now lands before the test reads. Fix the tests (and the docstrings on the application's target function) to match SDK behavior: MaxHits=3 -> 3 snapshots emitted, breakpoint disables on the 4th hit. Send a 4th request to actually probe the disabled state, and widen the disabled-state observation window to 5s so any spurious 4th snapshot has plenty of time to flush before we assert the breakpoint stayed disabled.

The SDK's increment_hit_count uses `hit_count > config.max_hits` for the disable check (instrumentation_manager.py:631), so MaxHits=N emits N snapshots and disables on the (N+1)th hit. The DI Flask, FastAPI, and Django hit-limit contract tests expected N-1 snapshots, claiming the check was `>=` in their docstrings and inline comments — neither matched the SDK. The tests were passing on main by accident: BatchLogRecordProcessor's default schedule_delay_millis was 5000ms, so the snapshot emitted on the 3rd hit was still sitting in the batch buffer when the test's 2-second sleep elapsed and read the collector. core 1.41.0 tightened the default to 1000ms (open-telemetry/opentelemetry-python#4998), shrinking the window enough that the 3rd snapshot now lands before the test reads. Fix the tests (and the docstrings on the application's target functions) to match SDK behavior: MaxHits=3 -> 3 snapshots emitted, breakpoint disables on the 4th hit. Send a 4th request to actually probe the disabled state, and widen the disabled-state observation window to 5s so any spurious 4th snapshot has plenty of time to flush before we assert the breakpoint stayed disabled.

) ## Summary The DI Flask `DIFlaskHitLimitTest` and the matching application target function had `MaxHits` semantics flipped relative to the SDK. With `MaxHits=3`, the test expected 2 snapshots, claiming the disable check was `hit_count >= max_hits`. The SDK's [increment_hit_count](https://github.com/aws-observability/aws-otel-python-instrumentation/blob/main/aws-opentelemetry-distro/src/amazon/opentelemetry/distro/debugger/instrumentation_manager.py#L631) actually uses `hit_count > max_hits`, so it emits 3 snapshots and disables on the 4th hit. ## Why this is surfacing now The test was passing on main by accident. `BatchLogRecordProcessor`'s default `schedule_delay_millis` was 5000ms, so the snapshot emitted on the 3rd hit was still sitting in the batch buffer when the test's `time.sleep(2)` elapsed and read the collector. The 3rd snapshot never reached the mock collector within the test's observation window. OpenTelemetry core 1.41.0 [tightened that default to 1000ms](open-telemetry/opentelemetry-python#4998) to comply with the OTel spec, so the upcoming dependency bump to 1.42.1 / 0.63b1 (#762) now sees the 3rd snapshot consistently and the latent off-by-one assertion fails the test. ## Changes - Update the test class docstring and both test methods so `MaxHits=3` → 3 snapshots, breakpoint disabled on the 4th hit. Send a 4th request to actually probe the disabled state. - Update the `limited_function` docstring in the di-flask sample app to match. ## Test plan - [ ] DI Debugger Contract Tests pass on this branch (currently the only test in the suite that was failing, on the `nightly-dependency-updates` branch) - [ ] No SDK behavior change — purely a test/comment alignment with current SDK semantics

Fix BatchLogRecordProcessor default schedule_delay_millis to 1000ms p…

3979f16

…er OTel spec

Manvi2402 requested a review from a team as a code owner March 18, 2026 15:18

github-project-automation Bot added this to Python PR digest Mar 18, 2026

pmcollins reviewed Mar 18, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

Update OTEL_BLRP_SCHEDULE_DELAY docstring default to 1000ms and fix C…

039ef13

…HANGELOG

themavik reviewed Mar 19, 2026

View reviewed changes

pmcollins approved these changes Mar 19, 2026

View reviewed changes

xrmx reviewed Mar 19, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

Apply suggestion from @xrmx

4a52e74

xrmx approved these changes Mar 20, 2026

View reviewed changes

Merge branch 'main' into fix/batch-log-processor-schedule-delay

06eb065

xrmx moved this to Approved PRs in Python PR digest Mar 20, 2026

herin049 approved these changes Mar 21, 2026

View reviewed changes

DylanRussell reviewed Mar 27, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

DylanRussell reviewed Mar 27, 2026

View reviewed changes

Comment thread opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/export/__init__.py

Manvi2402 added 2 commits March 28, 2026 08:22

Update CHANGELOG wording to 'may be' for export frequency

73b03f3

Merge branch 'fix/batch-log-processor-schedule-delay' of https://gith…

c058b51

…ub.com/Manvi2402/opentelemetry-python into fix/batch-log-processor-schedule-delay

xrmx requested a review from DylanRussell April 1, 2026 15:31

xrmx reviewed Apr 3, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

xrmx added 2 commits April 3, 2026 10:25

Apply suggestion from @xrmx

96514cd

Merge branch 'main' into fix/batch-log-processor-schedule-delay

0ed243d

xrmx enabled auto-merge (squash) April 3, 2026 08:28

xrmx merged commit d9a8c70 into open-telemetry:main Apr 3, 2026
508 checks passed

github-project-automation Bot moved this from Approved PRs to Done in Python PR digest Apr 3, 2026

liustve mentioned this pull request Jun 16, 2026

test(debugger): align DI hit-limit test with SDK MaxHits semantics aws-observability/aws-otel-python-instrumentation#782

Merged

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix BatchLogRecordProcessor default schedule_delay_millis to 1000ms per OTel spec#4998

Fix BatchLogRecordProcessor default schedule_delay_millis to 1000ms per OTel spec#4998
xrmx merged 8 commits into
open-telemetry:mainfrom
Manvi2402:fix/batch-log-processor-schedule-delay

Manvi2402 commented Mar 18, 2026

Uh oh!

pmcollins left a comment

Uh oh!

Uh oh!

Manvi2402 commented Mar 19, 2026

Uh oh!

themavik left a comment

Uh oh!

Manvi2402 commented Mar 19, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

Manvi2402 commented Mar 18, 2026

Description

Type of change

How Has This Been Tested?

Does This PR Require a Contrib Repo Change?

Checklist:

Uh oh!

pmcollins left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Manvi2402 commented Mar 19, 2026

Uh oh!

themavik left a comment

Choose a reason for hiding this comment

Uh oh!

Manvi2402 commented Mar 19, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants