Artur Souza

Not sure if this is worth a proposal in proposals repo. Thoughts?

> @artursouza can't this be done only at `daprd` by allowing to override `consumerID`? I thought about that but `consumerID` seems to be a composite key at this point and...

> Is this about making sure all instances of the same app ID all receive a copy of a message? No, this is about a single app receiving the same...

> Tricky thing with this proposal is that it's very much broker-dependent. Related issue: #5244 > > As it is today, we have 3 kinds of brokers: > > 1....

> > > Is this about making sure all instances of the same app ID all receive a copy of a message? > > > > > > No, this...

There is at least one component that manually handles consumerID but I think it is fine if that is done after the runtime appends subscriberID: https://github.com/dapr/components-contrib/blob/master/pubsub/mqtt/mqtt.go I updated the proposal...

First, I propose that we don't make low cardinality the default behavior in 1.14. Instead, we use 1.14 to implement the following in low cardinality: - Allow regex of URL...

Addressing another point, low cardinality should be fine with adding path=/dapr/config or path=/healthz and any other Dapr-specific paths without an identifier.

I think there is a better solution than the custom regex. Dapr (in both low and high cardinality) would apply a series of builtin regexes to remove identifiers from the...

> > Ideally, we converge into low cardinality with automatic ID removal being the default behavior > > Do you mean converge into `high` cardinality? I mean that eventually (not...