test(feat-002): bump test_size_cap_rejection budget 100ms → 500ms (mitigates #20)

[brettheap]

Summary

• Bumps tests/unit/test_envelope_body_invariants.py::test_size_cap_rejection_under_100ms budget from 100 ms to 500 ms, and renames the test accordingly.
• Temporary mitigation for a consistent CI failure: the test landed at 160–168 ms across 4 recent runs of PR #19 — well above the 100 ms budget and blocking unrelated downstream work.
• This is not a fix. Issue #20 tracks the root-cause investigation and the path back to the original 100 ms budget.

Why now

This single test is the only thing failing CI on PR #19 (FEAT-011 spec + US1 MVP). The failure is environmental / consistent (not a one-off flake), so retrying won't help. Without this bump, downstream PRs stay red on CI for reasons unrelated to their own scope.

Why not just lower the budget silently

The 100 ms target reflects a real SC-009 performance invariant from FEAT-002 (body_too_large rejection is a single length comparison after rendering, so should be cheap). Bumping the budget without flagging the regression would silently weaken the contract. The bumped test's docstring + assertion message both reference issue #20 so future contributors don't mistake 500 ms for the contractual target.

Safety of the new bound

500 ms is large enough to absorb expected CI runner variance (the worst observed was 168 ms) without making the test useless. If serialize_and_check_size regressed to, say, 1 second, this test would still catch it. The intent is "won't fire on a healthy CI runner" rather than "restates the SC-009 latency invariant."

Test plan

• pytest tests/unit/test_envelope_body_invariants.py — 13 tests pass locally (was 13 passing pre-bump; rename is the only diff).
• CI on this PR — the renamed test_size_cap_rejection_under_500ms should pass comfortably (4 recent CI observations land at 160–168 ms, well under the new 500 ms ceiling).
• After merge — PR FEAT-011 (1/?): spec, plan, US1 MVP for app.* socket namespace #19's CI should go green (subject to any other CI changes since its last push).

Follow-up

Issue #20 owns the real fix: profile serialize_and_check_size against a 1 MiB body on a CI-class runner, identify the regressed step, restore (or justify) the original budget. When that lands, this test reverts to test_size_cap_rejection_under_100ms and this PR becomes obsolete.

🤖 Generated with Claude Code

Summary by Sourcery

Relax the performance budget and update documentation for the envelope body size-cap rejection test to unblock CI while a regression is investigated.

Tests:

• Rename the size-cap rejection latency test to reflect a 500 ms budget and adjust its assertion threshold accordingly.
• Expand the test docstring and failure message to document the temporary nature of the relaxed latency budget and reference the follow-up regression investigation (issue FEAT-002: investigate perf regression in test_size_cap_rejection_under_100ms (160-170ms in CI vs 100ms budget) #20).

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Temporarily relaxes and documents the latency budget for the body_too_large rejection test to unblock CI while clearly pointing to issue #20 as the root-cause investigation and future path back to 100 ms.

File-Level Changes

Change	Details	Files
Relax and document the performance budget of the size-cap rejection test to mitigate a CI regression while preserving the original 100 ms target in documentation.	Rename the latency test from asserting rejection under 100 ms to under 500 ms, updating the function name accordingly. Expand and rewrite the test docstring to explain the temporary nature of the 500 ms budget, reference issue FEAT-002: investigate perf regression in test_size_cap_rejection_under_100ms (160-170ms in CI vs 100ms budget) #20, and clarify that 100 ms remains the intended SC-009 invariant. Adjust the assertion threshold from 0.100 to 0.500 seconds and update the failure message to mention the 500 ms budget and link back to issue FEAT-002: investigate perf regression in test_size_cap_rejection_under_100ms (160-170ms in CI vs 100ms budget) #20.	tests/unit/test_envelope_body_invariants.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider extracting the 500 ms budget into a named constant (e.g., SIZE_CAP_REJECTION_BUDGET_S) so that the temporary nature and eventual reversion to 100 ms are centralized and easier to update.
• The test docstring is quite long and mixes behavior description with operational history; you might move the mitigation narrative and issue reference into a code comment to keep the docstring focused on the test’s intent.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider extracting the 500 ms budget into a named constant (e.g., `SIZE_CAP_REJECTION_BUDGET_S`) so that the temporary nature and eventual reversion to 100 ms are centralized and easier to update.
- The test docstring is quite long and mixes behavior description with operational history; you might move the mitigation narrative and issue reference into a code comment to keep the docstring focused on the test’s intent.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

This PR updates a FEAT-002/SC-009 performance budget in tests/unit/test_envelope_body_invariants.py to mitigate a consistent CI regression tracked in issue #20, unblocking downstream work while keeping a guardrail in place.

Changes:

• Renames test_size_cap_rejection_under_100ms → test_size_cap_rejection_under_500ms.
• Relaxes the elapsed-time assertion from 100 ms to 500 ms and updates the docstring/assertion message to explicitly reference issue #20.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.