Sending to 2 topics with the same payload and transactionId still delivers twice to same user
Ie if:
- user A is subscribed to both Topics 1 and 2, and
- I send the same:
- notification
- workflow
- payload
to both topics
...shouldn't this deliver the notification to user A only once?
I currently see duplicate notifications, one from each topic.
This is so that we can have users subscribe to individual events from a client ("package is late"), or to ALL events for a client (which I have set up as separate topics).
Ideally if the user subscribed to ALL, I don't have to delete them from the individual topics
So if they change their mind and want to go back to individual client events, they don't lose their setup of which topics they were previously subscribed to.
I have tried setting the transactionId in the payload as recommended here:
https://docs.novu.co/workflows/notification-workflows#faqs
...but I am still seeing the notification being delivered twice. Can I prevent this somehow?
Example transactionId I tested with is
d3d74d27-f3aa-5d4d-81e2-d03b65123d1a14 Replies
Hi @brucek, I'm an AI assistant for Novu. While a team member reviews this question, I'll look through relevant sources and see if I can provide suggestions. Please tag @Ask Inkeep with any follow-up questions.
-----------------------------
While I generate an answer, here are some sources that might be helpful:
* Go
* Java
* Workflows
* Subscribers
-----------------------------
Answer
Based on the current Novu documentation and information provided, there isn't a detailed mechanism described for preventing duplicate notifications to the same user subscribed to multiple topics with the identical notification, workflow, and payload, even with the use of a
transactionId. The documentation does not provide a direct answer to handling duplicates in this specific scenario.
For your use case of wanting to ensure a user does not receive duplicate notifications when subscribed to multiple topics, considering the documentation does not explicitly address this scenario, it might be worth exploring alternative approaches to managing your subscriptions and notification triggers. This could involve server-side logic to check subscription overlaps before sending notifications or implementing a more nuanced handling of topic subscriptions and notification dispatching based on user preferences.
If the issue persists and is significantly impacting your use case, considering reaching out directly to Novu's support or community might provide more tailored solutions or workarounds specific to the platform's current capabilities and limitations.
Got it. Tagging @Support for additional help.Hey @brucek can you elaborate a bit more about the use case? The way the API is working, and what you described is the expected behavior, but I'd love to understand a bit more the requirement so we can find the best approach to solve that.
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 topics)
- 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 🙏Hey @brucek thanks for the info! Let me run this with the team and get back to you. @Pawan Jain @Dima Grossman @radek @Ryan Reynolds take a look here
@brucek this is good feedback and appreciate the level of detail. It may be a good idea to jump on a quick call this week. We can use the time to discuss and propose suggestions on this, and cover any other parts of your project where we may be able to assist.
If you’d like, shoot me an email at [email protected] and we can get something in the calendar.
Hey @Ryan Reynolds , I sent you an email here a few days ago, just making sure it arrived 🤞
@brucek, you just advanced to level 1!
Hi @brucek - I’m AFK right now but you should have seen something from me early yesterday morning. Let me get back to my computer to check. There’s a link there to directly book time.
Ok thanks I’ll check spam etc too on my side
Nope, still can't find anything in my email 😕
@brucek
Thanks for sharing the usecase in detail
idempotency by transactionId here means, if you trigger any workflow using same
transactionId, Novu will not send notification again.
I think you mis understood this as triggering to two topics at once
This is how you can use Novu for your usecase:-
1. Create topic for parent node
2. create topic for leaf nodes
3. Add those users in leaf node topics who are interested in any particular leaf node
4 if any user is interested in all leaf nodes, instead of adding that user in all leaf nodes (remove if previously added), add that user only in parent nodeThanks @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)@brucek
I agree with you above storing state separately for this on your side is not a good approach.
Thanks for sharing
novu-ruby sdk issue.
cc:- @unicodeveloper@brucek we are experimenting with a wildcard approach to topic execution for example, let's take in to account the following topics:
clients/:clientId
clients/:clientId/sub-leaf-project/:projectId/likes
clients/:clientId/sub-leaf-project/:projectId/comments
And during trigger using a wildcard solution like: trigger({ topic: 'clients/1234/**' });
In this case a customer might subsribe to nested wildcard and will have the possibilitty of overriding a bottom leaf node to disable notifications for example.
Will this work for your given workflow?@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 🙌
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.