CAP
CAP copied to clipboard
dotnetcore
When using RedisStreams only one ConsumerGroup is created
Fixed RedisStream.Manager.Extensions.TryGetOrCreateStreamGroupAsync to create ConsumerGroup when not found.
When using RedisStreams as a transport along with multiple Consumer Groups - the current implementation throws exception when staring subscriber that has different consumer group that the one that created the stream. It seems like creation part was missing from TryGetOrCreateStreamGroupAsync method.
@mlatoszek , Could you please confirm if I understood correctly the issue, you had two deployed instances that use CAP RedisStreams , and each one of them has a unique DefaultGroupName, or do both instances use the same name? as if they use different names, this is already handled when reading the stream group by StreamName and then filtering the group by DefaultGroupName after that we are creating the group if it was not there, you will find that in TryGetOrCreateStreamConsumerGroupAsync method the public one
Hi @MahmoudSamir101,
The issue occurs when there are two instances with different consumer group name - using the same stream. Please see the code below:
if (streamExist) the second consumer group will not be created as the operations ends on checking if there is already a consumer group with the same name registered in the stream - but if there isn't - nothing happens.
That's why TryGetOrCreateStreamGroupAsync IMO should create consumer group in the stream, if it does not exist. The name of this method suggest it.
@mlatoszek , you are right, we do nothing if a stream was created from one of the consumer groups Thanks for the fix
My pleasure @MahmoudSamir101 :) Btw. do you know when can it be merged and the fix released with new nugets? I need it in order to use CAP in our project. I can create nugets myself and release it to our private repo but would be great to use official ones ;)
Hi @MahmoudSamir101 , You can review and merge this PR directly, and I will push the 6.2.1 preview verion to nuget
@yang-xiaodong should I keep the version.props changes or you will manage the version number
should I keep the version.props changes
Yes, that's exactly our next version number
Fixed in version 6.2.1-preview-180716003 and pushed to nuget in a few minutes ago.