Gracefully handle 429 Too Many Requests

I guess it is better to check the exception status code, like $e->getCode() == 429 instead of doing regular expression match on the message, this will be a bit easier.

And I think it is better to re-queue the items instead of do sleep inside this method from patch. Check queuer plugin, e.g. this one from purge module purge/modules/purge_queuer_coretags/src/Plugin/Purge/Queuer/CoreTagsQueuer.php, it is used in this service purge/modules/purge_queuer_coretags/src/CacheTagsQueuer.php. I think it is better to create some RetryQueuer plugin and just add failed invalidations back to the queue

I guess it is better to check the exception status code, like $e->getCode() == 429 instead of doing regular expression match on the message, this will be a bit easier.

oh, I was thinking to add the check for the code, so it looks like I've missed this. But checking the error message is needed to get the seconds needed to wait.

And I think it is better to re-queue the items instead of do sleep inside this method from patch. Check queuer plugin, e.g. this one from purge module purge/modules/purge_queuer_coretags/src/Plugin/Purge/Queuer/CoreTagsQueuer.php, it is used in this service purge/modules/purge_queuer_coretags/src/CacheTagsQueuer.php. I think it is better to create some RetryQueuer plugin and just add failed invalidations back to the queue

Of course, if it was using a queue, which is not the case if the API is invoked directly through a drush command.

All purging is done through the queue even the one that is invoked from drush command. I assume the fix from this patch should be enough. The queue item will be set to Failed, and according to QueueService "Failed" items go back to the queue automatically.

Just re-rolling.

Automatically closed - issue fixed for 2 weeks with no activity.