[8.x] Rename some queue configurations

[themsaid]

This PR does the following:

1. Deprecates the --delay option of the queue:workcommand.
2. Adds a --backoff option to the command to replace --delay.
3. Renames $retryAfter and retryAfter() to $backoff and backoff() on jobs, mailers, notifications, and listeners.
4. Changes $timeoutAt in jobs, notifications, and listeners to $retryUntil to match the name of the alternative retryUntil() method and not conflict with the $timeout property.

---

Marked as draft as I'm going to check there are no other confusing configurations on Monday. Just wanted to make it public for feedback.

[clarkeash]

• I think —delay is clearer than —backoff.
• I think ”The number of seconds before a released job will be available” Is better as the command description.
• if —delay is kept then I would keep retryAfter or rename to delayUntil

[trevorgehman]

• --delay is pretty bad and needs to be changed, but not sure that --backoff is much better.
• I agree with @clarkeash. Your command description update is a great improvement.

What if instead of backoff we'd do one of these:

Option 1:

• --retry-after
• $retryAfter/retryAfter()
• $retryUntil/retryUntil()

Option 2:

• --retry-delay
• $retryDelay/retryDelay()
• $retryUntil/retryUntil()

I know the issue with retryAfter() is that the config option for the queue connections includes a retry_after key, but it seems like that needs to be renamed to something like release_after.

[michaeldyrynda]

Instead of immediately renaming the methods, would you be open to adding the new methods, calling the methods they’re replacing internally, and marking the old methods @deprecated, then removing them in Laravel 9?

I know a major version allows for breaking changes, but deprecating them gives developers a more gradual ramp to update their code.

Alternatively, doing it this way would even allow you to introduce the new methods in a minor release in 7.x, add the deprecation notice, and remove in 8.0 if you really wanted to target that release. It’s only a ~3 month window from deprecation to removal, though.

[izshreyansh]

I think terminate is better explanation than backoff.

[shadoWalker89]

agree with @trevorgehman backoff is not a good replacement
agree with @michaeldyrynda it's better to deprecate it and remove it in a later version, and since there is no much time until 8.x maybe deprecate it in 7.x and remove it in 9.x

[themsaid]

Hey everyone,

backoff appears to be the closest-to-right term to use after researching the topic. We can't use retry-after because it's used in config/queue.php to imply a different thing.

We also don't want to use retry-delay because we want to keep the term "delay" used only for pushing jobs to be queued later.

As for deprecation notices. I think the change can be done via find-and-replace in your code editor so it won't make the upgrade too much difficult. So imo I think we can go ahead and rename the method/properties in 8.x

[michaeldyrynda]

As for deprecation notices. I think the change can be done via find-and-replace in your code editor so it won't make the upgrade too much difficult. So imo I think we can go ahead and rename the method/properties in 8.x

I think most changes can be some via find and replace, I don’t dispute that. It’s about deprecating methods more thoughtfully, and providing some notice - outside of a PR that not everybody is going to see - to give people a chance to deal with the deprecation.

[JosephSilber]

Others have already commented about the nomenclature of backoff here.

I just want to add that backoff has a certain connotation of gradually backing off, so that each time it fails the delay is increased 🤷‍♂️

[mfn]

Hello 👋🏼

I know no one asked for my opinion here, but what triggered me writing this comment is that, now that I was faced with the delay/backoff rename in a project and researched how this came about, I was under the same impression and thought "this doesn't feel right". As you said: "gradually backing off" was also my expectation

But, IMHO, turns out we're mostly just so used to the (indeed very common place) e.g. "exponential backoff" that it's easy to assume (even myself) the "backoff" equals "exponential backoff".

But in fact there are just different types of backoff one can do:

• linear
• constant
• exponential
• …

My 2c FWIW 😄