HTTP/2 stream was not closed cleanly: REFUSED STREAM

[yetdog]

This just started happening a couple of days ago. httpd log entry in the error_log:

PHP Fatal error: Uncaught Exception: HTTP/2 stream 99347 was not closed cleanly: REFUSED_STREAM (err 7) in /var/www/html/pushok/vendor/edamov/pushok/src/Client.php:153\nStack trace:\n#0 /var/www/html/push/push-pushmessage.php(301): Pushok\Client->push()\n#1 {main}\n thrown in /var/www/html/pushok/vendor/edamov/pushok/src/Client.php on line 153

Most pushes seem to go through (sending around ~50k w/ concurrency @ 40 and concurrent connections @ 5. But when I go to loop through my responses from APNS, nothing happens because the script fails on that client connection.

Thoughts??

[yetdog]

I haven't been able to test this theory specifically (I'm not going to hammer thousands of real devices with spammy messages), but it seems like there's some sort of upper limit per-client connection. That number appears to be ~50,000.

What I've done in my code is break my messages up into batches of 10,000. Each batch initiates a client connection, adds the 10,000 tokens to the notifications array, then attaches that to the client object, and finally pushes, then closes the connection. 10,000 more at a time until the end. So far, I'm not getting that error.

Just odd that this has come about all of a sudden. Likely nothing library-based (as nothing has changed), and more likely Apple has gotten more strict, without publishing any changelogs.

[edamov]

Thank you for the clarification! I am pleasantly surprised that you send such a big amount of notifications using this library

[yetdog]

Well, I really appreciate you creating and maintaining this lib, so thank YOU! I feel like the APNS communication was "solved" years ago and nobody bothers to keep things up to do (live activities, etc), and then when you narrow it down to a specific language (in this case PHP), it makes that needle even tougher to thread.

Happy to chat with you offline about my use case. But overall, yes, I push >50k at a time, and over the course of some evenings, >1M+. :) Your library is fantastic. My skills are just above "hack" so I appreciate folks like yourself who can put out production, consumable and customizable code like this. Thanks again.

[edamov]

Fantastic numbers :open_mouth:

[ryangittings]

@yetdog did you ever manage to fix this?

[omitech]

We're still experiencing the same issue, even after reducing the subscriber count to 5,000 per batch.

[yetdog]

@yetdog did you ever manage to fix this?

Sorry I haven't replied yet. My batch jobs seemed to fix it, yes. But bummed to hear @omitech is still having the issue. I would have to assume something on Apple's end changed and wasn't documented?

[omitech]

The problem is that it is not reproducible; sometimes it works, sometimes it does not. It looks like an issue on Apple's end, rather than with the library.

I'm using curl 7.86.0

[VladislavsIgnatjevs]

we also use this library and occasionally hit the same issue. The amount of push notifications varies - the last time this happened we only sent to just over 1500 subs.

Has anyone attempted to reduce "maximum concurrent streams" with custom curl options and get success?