fix: respect both local and remote HTTP/2 concurrent stream limits

[katpadi]

Fixes #140

Problem

delayed_push_async raises HTTP2::Error::StreamLimitExceeded on the 101st concurrent push. The http-2 gem enforces 2 independent limits remote (APNs, typically 1000) and local (http-2 default, 100) but only the remote was checked, allowing stream creation past the local limit.

Solution

• effective_max_concurrent_streams uses min(remote, local) so backpressure triggers before either limit is hit
• New max_concurrent_streams: option on Connection.new for explicit override
• Rescue StreamLimitExceeded in delayed_push_async as a safety net

Tests

• Added unit tests and an integration test that reproduces the exact bug
• scenario (server advertising 1000 streams, 101 concurrent pushes).

[k-tsuchiya-jp]

Hi @katpadi,

Thanks for the PR — I tested this on my side and confirmed that the original issue is resolved with your changes.

Previously, we were able to reproduce HTTP2::Error::StreamLimitExceeded when sending more than 100 concurrent async pushes, due to the mismatch between the http-2 local limit (100) and the higher peer limit (e.g. 1000 from APNs).
With this fix, that error no longer occurs in our environment.

The added spec also makes sense to me:

• the server advertises a higher concurrent stream limit (e.g. 1000)
• more than 100 async notifications are sent concurrently
• streams are intentionally kept in-flight to expose the old local limit behavior

This matches the production scenario we observed quite well.

The changes to the dummy server (allowing configurable settings_max_concurrent_streams and handling requests in a background thread) also look appropriate to properly simulate concurrent streams.

From my perspective, this fix looks correct and addresses the issue.

Thanks again for working on this!

[benubois]

Hi @katpadi,

Amazing, thank you!

Is it necessary to expose max_concurrent_streams as part of the public API?

• If there's not a good reason a user would set this let's remove it.
• If you think the option should stay, I'm happy to leave it in, but it should be documented in the README.

[katpadi]

@benubois - yeah, I agree. I removed max_concurrent_streams from the public API. There's no scenario where a user would need to override this. Exposing it only risks masking errors if someone sets it too high.

[benubois]

Thanks again!