You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When scheduling an event a lot of users (multicast or broadcast to huge number of subscrbers), let's say the time this takes is 10 minutes (maybe a million users). If we were to call the cancel endpoint in the middle of that 10 minutes span, the cancel endpoint would only cancel jobs that have already been created (scheduled).
👟 Reproduction steps
Run a script to create a lot of users (like > 10k)
Schedule it to a certain point in the future.
As soon as you schedule, cancel immediately.
Some of the messages will still arrive because they were created after the cancel event.
👍 Expected behavior
Perhaps we should keep track of which transaction id got cancelled and check that along with the job status enum?
Currently, even with checking both pending, delayed, and merged jobs don't suffice.
Because as I mentioned earlier, some of the jobs haven't even been scheduled. The loop inside trigger-broadcast-usecase.ts might still being run and things are still in the process of being sent to subscriberProcessQueueService.
Novu version
0.22.0
npm version
No response
node version
No response
📃 Provide any additional context for the Bug.
No response
👀 Have you spent some time to check if this bug has been raised before?
📜 Description
Hi, Novu team! Thanks for the amazing product.
When scheduling an event a lot of users (multicast or broadcast to huge number of subscrbers), let's say the time this takes is 10 minutes (maybe a million users). If we were to call the cancel endpoint in the middle of that 10 minutes span, the cancel endpoint would only cancel jobs that have already been created (scheduled).
👟 Reproduction steps
Run a script to create a lot of users (like > 10k)
Schedule it to a certain point in the future.
As soon as you schedule, cancel immediately.
Some of the messages will still arrive because they were created after the cancel event.
👍 Expected behavior
Perhaps we should keep track of which transaction id got cancelled and check that along with the job status enum?
In the transaction
cancel-delayed-usecase.ts
and then in
run-job.usecase.ts
, we check the cancel status like so👎 Actual Behavior with Screenshots
Currently, even with checking both pending, delayed, and merged jobs don't suffice.
Because as I mentioned earlier, some of the jobs haven't even been scheduled. The loop inside
trigger-broadcast-usecase.ts
might still being run and things are still in the process of being sent to subscriberProcessQueueService.Novu version
0.22.0
npm version
No response
node version
No response
📃 Provide any additional context for the Bug.
No response
👀 Have you spent some time to check if this bug has been raised before?
🏢 Have you read the Contributing Guidelines?
Are you willing to submit PR?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered: