brucek
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Just curious, would nested wildcards also be supported?
Ie:
- user D subscribes to parent wildcard, child wildcard, and subleaf, ie:
-
clients/1234/**
- clients/1234/sub-leaf-project/1/**
- clients/1234/sub-leaf-project/1/comments
- the subleaf topic fires (clients/1234/sub-leaf-project/1/comments
)
==> user D only gets delivery on the top-most parent topic (clients/1234/**
), and not on either the leaf or child topic subscriptions
I don't think this is critical for us today, but I suspect it would be useful as we build out our notification system over time so I'm just curious as I can imagine this implementation potentially not being much more complicated.21 replies
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
@Dima Grossman So if I understand correctly:
- user A is subscribed to all subleaf topics
- user A is also subscribed to parent wildcard topic (
clients/1234/**
)
- trigger fires notification for a subleaf topic (clients/1234/sub-leaf-project/1/comments
)
- instead of the subleaf topic notification triggering, the parent wildcard topic overrides and fires instead
==> the notification is only sent to user A on the parent wildcard topic (and not on the subleaf topic)
- user B is only subscribed to the subleaf
==> the notification is sent to user B only on the subleaf topic
- user C is only subscribed to the parent wildcard topic
==> the notification is sent to user C only on the parent wildcard topic
If that is correct then yes this 100% will solve my problem 🙌21 replies
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Thanks @Pawan Jain .
FWIW, I am triggering the same workflow using the the same
transactionid
(and even the same payload, just with different topics), which is why I would expect that to prevent duplicate deliveries
The issue I face with your solution is if a user:
1. sets up a bunch of leaf nodes
2. switches to a parent node temporarily
3. later turns off parent again
==> in this case, the user should re-subscribe again to previously subscribed leaf nodes
In this case I either need to:
a. save the leaf node state on our side and re-add the user to leafs from our saved state, or
b. force the user to re-select all leafs (there may be 10-20+ per parent, which is burdensome, especially if they switch multiple parents on/off multiple times)
I dislike the solution of saving state on our side since all our other notification/subscription state is saved in Novu
It would be slightly easier if I could see all / a filtered set of subscriptions for a user, but I don't see a way to do that in Novu either
And every time when suibscribing to a parent, I would have to make a Novu call for each leaf topic to see if the user has subscribed to it, then save those topics, then later make again a Novu call for each topic to re-subscribe
I am working in Ruby where the novu-ruby
client takes like 500ms per call, and which uses HTTParty which does not seem to support aync calls - https://webscraping.ai/faq/httparty/is-it-possible-to-make-asynchronous-requests-with-httparty), so these operations could normally take seconds, meaning I probably have to run them through a background process which adds more complexity (vs just a single Novu call to subscribe/unsubscribe from the parent)21 replies
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Nope, still can't find anything in my email 😕
21 replies
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Ok thanks I’ll check spam etc too on my side
21 replies
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Hey @Ryan Reynolds , I sent you an email here a few days ago, just making sure it arrived 🤞
21 replies
NNovu
•Created by brucek on 3/30/2024 in #💬│support
Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Thanks @Tomer Barnea , basically:
- we have a hierarchy of notification topics
- at the top level is
Client
: notify me when anything happens with a specific client
- underneath each Client, we have a bunch of specific notifications (like 30-40) based on various events (product packed, product shipped, etc)
- some people only want to receive a few specific notifications for a Client
- occasionally, they will want to (temporarily) turn on all notifications for the Client
- then they will later want to turn that back off and only receive the specific notifications they had previously set up
The way I feel is natural here is:
- have specific Novu topics for each Client-notification combo (the "leaf" nodes")
- have a separate Novu topic for the Client (the parent node)
- a user can subscribe to some set of leaf nodes
- when an event fires, I trigger both the leaf topic as well as the parent Client topic
- a user can subscribe to the parent Client topic, so the 2 triggers will fire both the parent and the leaf topic
- this is where I'd like to de-dup and have only a single delivery (which I would expecte transactionId
to do for me, since it is the same workflow
, payload
, and recipient, just different topic
s)
- the user can then unsubscribe from the parent Client topic and go back to the previous, leaf-only notifications (without having to go and set them all up again from scratch)
Let me know if you want more info or have other ideas for me, thank you 🙏21 replies