[PR #12830/93a2b1c3 backport][3.14] Bound pipelined request queue per connection

[bdraco]

This is a backport of PR #12830 as merged into master (93a2b1c).

What do these changes do?

On the server, parsed HTTP/1 requests are queued per connection while one handler is active. There was no bound on how many complete pipelined requests could be buffered behind a busy handler.

This adds a per-connection cap (MAX_MSG_QUEUE_SIZE, 32) that works at two layers:

• The parser stops emitting messages once that many are queued unconsumed. The C parser pauses llhttp between messages and buffers the remainder as tail; the pure-Python parser does the same with its tail buffer. A new message_consumed() frees a slot.
• RequestHandler pauses the transport when the queue is full and resumes once the handler drains it to half the limit, reparsing the buffered pipeline in batches.

A max_msg_queue_size of 0 keeps the old unbounded behavior, so the parser classes are unchanged for other callers.

Are there changes in behavior for the user?

A single connection can now have at most MAX_MSG_QUEUE_SIZE parsed pipelined requests waiting behind the active handler; reading is paused past that and resumes as the queue drains. Normal request/response and pipelining within the bound behave as before.

Is it a substantial burden for the maintainers to support this?

No.

Related issue number

N/A

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes N/A
• If you provide code modification, please add yourself to CONTRIBUTORS.txt N/A, already listed
• Add a new news fragment into the CHANGES/ folder

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.23%. Comparing base (4f7480e) to head (51d84f4).
⚠️ Report is 85 commits behind head on 3.14.

Additional details and impacted files

@@            Coverage Diff             @@
##             3.14   #12854      +/-   ##
==========================================
+ Coverage   98.08%   98.23%   +0.14%     
==========================================
  Files         133      135       +2     
  Lines       48170    48590     +420     
  Branches     2567     2607      +40     
==========================================
+ Hits        47248    47732     +484     
+ Misses        735      678      -57     
+ Partials      187      180       -7     

Flag	Coverage Δ
CI-GHA	98.28% <100.00%> (+0.14%)	⬆️
OS-Linux	98.06% <100.00%> (+0.14%)	⬆️
OS-Windows	95.75% <100.00%> (+0.49%)	⬆️
OS-macOS	97.25% <100.00%> (+0.02%)	⬆️
Py-3.10	97.44% <100.00%> (+0.85%)	⬆️
Py-3.11	97.71% <100.00%> (+0.62%)	⬆️
Py-3.12	97.80% <100.00%> (+0.24%)	⬆️
Py-3.13	97.77% <100.00%> (+0.91%)	⬆️
Py-3.14	97.89% <100.00%> (+0.93%)	⬆️
Py-3.14t	96.87% <100.00%> (?)
Py-pypy-3.11	96.72% <100.00%> (?)
VM-macos	97.25% <100.00%> (+0.02%)	⬆️
VM-ubuntu	98.06% <100.00%> (+0.14%)	⬆️
VM-windows	95.75% <100.00%> (+0.49%)	⬆️
cython-coverage	38.40% <75.49%> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[codspeed]

Merging this PR will improve performance by 10.43%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 71 untouched benchmarks
⏩ 7 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	test_get_request_with_251308_compressed_chunked_payload[isal.isal_zlib-pyloop]	74 ms	67 ms	+10.43%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing patchback/backports/3.14/93a2b1c369d69ca6fcdabea9a7c29cfc7947817c/pr-12830 (51d84f4) with 3.14 (14b6ee8)²}

Footnotes

1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on 3.14 (0e9cedd) during the generation of this report, so 14b6ee8 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩