…is) (toooni)This PR was merged into the 5.1-dev branch.Discussion----------[Messenger] Add receiving of old pending messages (redis)| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Tickets       || License       | MIT| Doc PR        |symfony/symfony-docs#12976This PR makes it possible for the redis transport to get abandoned messages from not running/idle consumers by using `XPENDING` and `XCLAIM`.Usually it would be best to let the claiming of pending messages be handled by a separate command. Since the messenger component's commands are fixed, we do need to set a `claimTimeout`. The `claimTimeout` defines how long an idle message should be left alone until it will get claimed by the current consumer (Must be a value higher than the longest running handling time of a message or else the message will be handled twice).Using this solution makes the remarks (symfony/symfony-docs#11869 (review)) regarding not being able to use the hostname as consumer name obsolete. I would even recommend the hostname as the consumer name.**Questions**- [x] Which value should we use as default `claimTimeout`?- [x] How should the `claimTimeout` be configured?- [x] Feature or Bugfix?I will create a docs PR and a PR for the other branches as soon as the questions are resolved.Commits-------9cb6fdf Implemted receiving of old pending messages

…Seldaek)This PR was merged into the 5.1-dev branch.Discussion----------[RedisMessengerBridge] Add a delete_after_ack optionThis allows Messenger to clean up processed messages from memory, avoiding a mem "leak" in redis| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Tickets       |#33715| License       | MIT| Doc PR        | symfony/symfony-docs#... TODO - will pile it on tosymfony/symfony-docs#11869 as it kinda binds together and a bigger refactor of the docs here is much needed to avoid all these gotchasRight now by default a redis transport for messenger will leak memory as all messages stay in redis forever. You can configure `stream_max_entries` to automatically trim to a max of X entries, but that means if you have big peaks in messages you might start losing messages which have not been processed.This PR provides an alternative to that, by deleting message as they are processed. This is ideal as it avoids having to find the right number for `stream_max_entries` (do you want to risk losing data or use more memory than needed on average?). The only catch is that if you have multiple groups consuming the same stream, the first one processing a message will delete it, so other groups will not see it. For that reason `setup()` attempts to detect this and fails hard if it is misconfigured to prevent data loss.Commits-------7c416a7 [RedisMessengerBridge] Add a delete_after_ack option to automatically clean up processed messages from memory

…aelo)This PR was merged into the 5.2 branch.Discussion----------[Messenger] More on unique Redis consumer namesI managed to miss the warning that the (strem,group,consumer) combination must be unique. I think it would make it less easy to miss if it was also mentioned in the Supervisor section, so I've tried to add a mention of it there. I also expanded the original warning block a bit.There are many different combinations of transports and ways to manage workers, so I understand that the docs should not delve too deep into each one, but I think it's worthwhile to cover the Redis + Supervisor combo quite well, since it's one of the easier combinations to get started with, which also can work really well. Let me know what you think.Related:#11869  #35358Commits-------e73e923 [Messenger] More on unique Redis consumer names