Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JetStream: incorrect consumer num_pending against stream with subjects ending in .> #5608

Closed
scottf opened this issue Jun 28, 2024 · 4 comments · Fixed by #5610
Closed

JetStream: incorrect consumer num_pending against stream with subjects ending in .> #5608

scottf opened this issue Jun 28, 2024 · 4 comments · Fixed by #5610
Labels
defect Suspected defect such as a bug or regression

Comments

@scottf
Copy link
Contributor

scottf commented Jun 28, 2024

Observed behavior

A new generic consumer reports more num_pending than actual messages in the stream.

Expected behavior

The consumer reports the correct num_pending.

Server version

2.10.10 or later. (Tested against 2.10.9 the information was reported correctly)

Steps to reproduce

Create a consumer against attached data, nats consumer create give it a name and all defaults. Look at the consumer info, it shows "Unprocessed Messages: 5,803". There are only 5670 messages.

Notes

All subjects end with .> (dot greater) as in OrchestrationStream_08fa7d3dcd644745bace255d2c76fbc2.>

Data

nats_cache.zip
stree_wildcard.zip

@scottf scottf added the defect Suspected defect such as a bug or regression label Jun 28, 2024
@scottf
Copy link
Contributor Author

scottf commented Jun 28, 2024

Originally reported as a discussion in the Java repo: https://github.com/nats-io/nats.net/discussions/905

@derekcollison
Copy link
Member

Can this be re-produced against main?

@scottf
Copy link
Contributor Author

scottf commented Jun 28, 2024

Can this be re-produced against main?

I used the data with 2.10.17 the first time I was able to reproduce it. I only checked the older versions after Wally explained to me about stree and so I just tested starting with the version he suggested until I found the one it stopped working in.

@neilalexander
Copy link
Member

Have figured out the problem. The stree Match was firing the callback twice for OrchestrationStream_08fa7d3dcd644745bace255d2c76fbc2.>, which had 133 messages, and 5803-133=5670. Posted a PR to fix it.

derekcollison added a commit that referenced this issue Jul 1, 2024
On a full wildcard `Match`, we were iterating through children but then
also falling through to a regular continuation instead of returning,
which meant that the `Match` callback could fire twice for the same
filter.

Fixes #5608.

Signed-off-by: Neil Twigg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect Suspected defect such as a bug or regression
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants