test(debugger): align DI hit-limit test with SDK MaxHits semantics

[liustve]

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 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 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

[github-actions]

Claude finished @liustve's task in 1m 50s —— View job

---

Claude PR Review

• Read prior reviews/comments (none)
• Read PR diff
• Verified SDK semantics in instrumentation_manager.py
• Examined the PR-modified test files
• Posted review

---

Verdict: LGTM

The change correctly aligns the test with the SDK's actual behavior. I verified the SDK at aws-opentelemetry-distro/src/amazon/opentelemetry/distro/debugger/instrumentation_manager.py:622-644:

state.hit_count += 1
...
if config and not config.is_permanent and state.hit_count > config.max_hits:
    state.is_disabled = True
    ...
    return False

With max_hits=3 and the strict > check, hit_count progresses 1 → 2 → 3 (all pass, three snapshots emitted), and only on the 4th hit does hit_count=4 > 3 evaluate true and disable. The new test expectations of 3 snapshots and a 4th request that does not produce a snapshot match this exactly.

Notes on robustness

• test_breakpoint_disabled_after_hit_limit waits time.sleep(2) after the 4th request before peeking. Since the 4th hit returns from increment_hit_count before any capture happens, no snapshot is ever emitted; the sleep is only needed as a safety margin against a false-positive flush. With the new OTel core default of 1000 ms schedule_delay_millis, a 2s sleep gives ~2× headroom — fine.
• wait_for_snapshots(min_count=3) does a >= check, so the subsequent assertEqual(initial_count, 3) is still the actual exactness gate. Good.
• Docstrings on both the test class and limited_function now agree with the SDK (hit_count > max_hits). No stale comments left behind.

No new findings to post inline.
· Branch

[github-actions]

Claude finished @liustve's task in 1m 58s —— View job

---

Claude PR Review

• Read prior reviews/comments
• Read PR diff (gh pr diff 782)
• Verified the only delta vs. the previously reviewed commit
• Posted review

---

Verdict: LGTM — no new findings

Compared to the previously reviewed commit, the only material change in the latest push is bumping time.sleep(2) → time.sleep(5) after the 4th request in both flask_test.py and fastapi_test.py. This is purely a wider safety margin over the OTel core 1.41.0 BatchLogRecordProcessor default (schedule_delay_millis=1000) — strictly more conservative, no behavioral risk.

Everything else (SDK semantics alignment with hit_count > max_hits, the 4-request probe of the disabled state, and the matching docstrings on limited_function and the test classes) was already verified in the prior review. SDK behavior at aws-opentelemetry-distro/src/amazon/opentelemetry/distro/debugger/instrumentation_manager.py:631 confirms hit_count > max_hits, so MaxHits=3 → 3 emitted snapshots, disabled on the 4th hit, which is exactly what the new assertions encode.

Following the dedup guidance, I am not re-posting findings already covered by the earlier review on this PR.
· Branch

[github-actions]

Claude finished @liustve's task in 1m 29s —— View job

---

Claude PR Review

• Read prior reviews/comments
• Read PR diff (gh pr diff 782)
• Confirmed no new commits since last review
• Posted review

---

Verdict: LGTM — no new findings

The current head (d6cb052) is the same commit covered in the prior review at 22:51:37Z. There are no new commits, files, or behavioral changes to review since the last pass — this trigger fired on the same SHA.

For convenience, summary of what's been verified across the prior reviews on this PR:

• SDK semantics at aws-opentelemetry-distro/src/amazon/opentelemetry/distro/debugger/instrumentation_manager.py:631 use hit_count > max_hits, so MaxHits=3 emits 3 snapshots and disables on the 4th hit. The new test expectations encode this exactly.
• Both flask_test.py and fastapi_test.py send 4 requests, assert 3 snapshots after the first 3, and assert no additional snapshot after the 4th — matching the SDK.
• django_test.py mirrors the same shape.
• Docstrings on limited_function (di-flask, di-fastapi) and on the test classes were updated to match the SDK and don't leave any stale >= claims.
• The time.sleep(2) → time.sleep(5) bump (the only delta in the most recent push) is a strictly more conservative observation window over OTel core 1.41.0's schedule_delay_millis=1000 default — no behavioral risk.

Per dedup guidance, not re-posting findings already covered by prior reviews.
· Branch