isaiahdahl
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
Sweet, let me know if I need to rebase or whip it up from a different branch or something.
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
Could it be just this easy?
https://github.com/novuhq/novu/pull/6489
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
It looks like the WorkflowQueueService and QueueBase Service already pass in job options to bullmq, so it's just a matter of adding priority as an option to the event trigger usecases.
for example https://github.dev/novuhq/novu/blob/08bd4266fab88417a974b06b3a502fd96d7354ed/apps/api/src/app/events/usecases/parse-event-request/parse-event-request.usecase.ts#L140-L141
if at here there was a way to know whether or not the workflow was critical or not, which seems liek it's readily available from line 47, then it should be a pretty simple check to just set the
options: { priority : 1 | 2} sorta thing.31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
Yeah I've seen that. That's mostly workflow creating/editing changes though right? or or is there alot of re-write in the whole system that's breaking?
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
Ok so are you indicating that you already have some kind of priority management in the roadmap and you'll add these comments?
Is this the type of thing you'd accept a partial implementation PR on? Like if it simply was just assigning a default priority of 2 to everything and then 1 if the workflow is critical=true?
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
It's less about whether or not the notification will eventually be processed or not. I'm assuming they would all process, It's about the timely manner for critical notifications.
Most importantly, I'm looking for critical notifications (ones people can't unsubscribe from) to not wait in queue behind less important marketing notifications. If I trigger 100k 'new-music' workflows when I trigger the 'password-reset' workflow for a customer, the queue picks that 'password-reset' workflow up earlier then if it was just FIFO.
That 'password-reset' workflow should end up in a customers inbox within ~45 seconds. But if i happen to have just queued up a big marketing drip, it could be like 20min before they got that email.
Yes self-hosting.
That 'password-reset' workflow should end up in a customers inbox within ~45 seconds. But if i happen to have just queued up a big marketing drip, it could be like 20min before they got that email.
Yes self-hosting.
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
@Tomer Barnea Sure thing!
Simply put I want to use Novu for system notifications that are critical ie. "Password Reset" or "You've Been Invited to Join "Person's" Team". But then I also want to use it to power some marketing drip/bucket campaigns. I would have like a "new-music-for-you" workflow that is triggered from our API with personalization context to generate an email with personalized songs (context: we're a Music Publishing company) . That "new-music-for-you" notification could trigger to 100k+ people. And when that happens, I wouldn't want the next "password-reset" notification to be stuck in line behind all of those "new-music-for-you" emails.
Does that make sense?
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
Other than ignoring subscriber status is there any other difference to how critical workflows are processed?
31 replies
NNovu
•Created by isaiahdahl on 9/9/2024 in #🚀│general
Notification Priority?
@Pawan Jain yes I’m aware and make use of that. But will events for critical workflows in the FIFO queue be processed in line with everything else?
31 replies
NNovu
•Created by isaiahdahl on 5/11/2024 in #💬│support
Sending email attachments "{"statusCode":413,"message":"request entity too large"}"
@george.d I ended up abandoning the approach because through debugging I think I discovered the problem I was facing was that I didn't have a s3 bucket configured for the upload to upload to. At the time I couldn't find it in documentation and I didn't understand that is how attachments worked in Novu.... but when I dug through the code I could see it was trying to put my attachment in a public s3 bucket for sending, which in my case I didn't have configured.
The use case I had couldn't have the attachment uploaded to a public bucket because it was attaching some financial report PDF data so I don't use Novu for that notification.
15 replies
NNovu
•Created by isaiahdahl on 5/11/2024 in #💬│support
Sending email attachments "{"statusCode":413,"message":"request entity too large"}"
15 replies
NNovu
•Created by isaiahdahl on 5/11/2024 in #💬│support
Sending email attachments "{"statusCode":413,"message":"request entity too large"}"
I'm encountering the error with something well under 20mb. Even attempting to attach a small 80kb PDF throws the error. base64 encoded as well as not.
We have the client_max_body_size set well above 20mb
15 replies