Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 5.x branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@chalasr I'll check this out. The queue needs to have delete_after_ack otherwise stream count will be completely incorrect, maybe return null for the count if delete_after_ack is not set on the connection? I can check some other scenarios around delayed and queued messages as well. Ultimately, I need to get at least a very close approximation as to the number of messages in the queue. Without being able to monitor these numbers, there is not a way I can spot queues that are not processing correctly.

Any pointers would be appreciated. Thanks 👍

As correctly linked by @chalasr the way to get the length would be what I have commented at: #31545 (comment). The problem here is that redis depending on your redis extension version does return the xinfo in different formats so this is not easy to parse to get the last-delivered-id correctly in all supported versions.

Aslong as delete_after_ack was set from the beginning xlen would return the correct count but if it was added later to the DSN it and the stream was not manually cleared then it would also not return the correct count for the messages which are expected. So not sure if I would depend on xlen in any case.

@chrishemmings Are you still working on this PR?

@chrishemmings Are you still working on this PR?

Hi there, for now I don't have time to look at this, it's turned into a more complex problem than I initially though. Closing.

To try reviving this issue; would the blocker we had earlier for getting this feature still be there?

Could we use a command like XPENDING for checking the Redis stream length? https://redis.io/commands/xpending/

No more blocker, the message count will be available for redis as of Symfony 6.2 thanks to #46229