This one's a small developer experience improvement that will save a lot of headaches. In this Laravel 10 application, I'm using the HTTP client's pool functionality to send three concurrent requests to convert GBP, USD and EUR all at the same time, and then I'm outputting those conversion rates on the frontend. The problem is, well, it's not the greatest API, as you can see here. More often than not, it's actually throwing a 500 error rather than returning a real result to me. So, you may have reached for something like the retry method on the HTTP client. For each of these items, why don't we retry them three times, and then we'll call get. In Laravel 10, nothing actually happened because retry was not supported in a HTTP pool.

For each of these items, why don't we retry them three times, and then we'll call get. In Laravel 10, nothing actually happened because retry was not supported in a HTTP pool. But in Laravel 11, it is. So if we switch over to this Laravel 11 codebase and tag on retry, we'll try each item three times and then reload the frontend, you'll see that now all of the results are returned correctly because when a 500 error is encountered, rather than just stopping short, it's going to attempt it again inside that asynchronous pool up to three times until it has a successful response. A very small change, but in my mind a very important change for consistency between how we use synchronous and asynchronous requests with the HTTP client.

A very small change, but in my mind a very important change for consistency between how we use synchronous and asynchronous requests with the HTTP client.