Seth/to arrays #39
Seth/to arrays #39
Conversation
(cherry picked from commit 8942f0d)
(cherry picked from commit 2ae026c)
(cherry picked from commit 14b0a63)
(cherry picked from commit 0eadce1)
This doesn't quite give us the ability to track how many were delivered, bounced, etc yet, as it does not tell us which email recipient bounced, or complained. They intend to improve the API early november at which point we can integrate that information
…ious if you send to 100 recipients for one email?
commit: |
| bounceCount: v.optional(v.number()), | ||
| complaintCount: v.optional(v.number()), | ||
| failedCount: v.optional(v.number()), | ||
| deliveryDelayedCount: v.optional(v.number()), |
There was a problem hiding this comment.
I worry that when things do fail, we'll get a flood of these. It'd be a great time to have the key-based batching workpool (I have ideas but not yet started) to enqueue events and handle them per-email... but right now I say we force a status query to get details by listing them all.
We could also surface a status that does a "distinct" lookup on the events for a given email, which would be bounded enough that for each email we could be checking e.g. if there were any bounces/ failures, etc. and maybe have the details of "how many" surfaced with an email-specific query. or just do the full count for now and see if folks with lots of to addresses need a more efficient one later..
src/component/lib.ts
Outdated
| ...email, | ||
| status: "failed", | ||
| finalizedAt: Date.now(), | ||
| failedCount: (email.failedCount ?? 0) + 1, |
There was a problem hiding this comment.
If we're going to update a global status, let's establish a hierarchy - so it will at most have each status once. e.g. if it got a complaint then maybe it never gets updated with any status after that.
suggestion to start:
- sent
- delivery_delayed
- delivered
- bounced
- opened
- clicked
- complained
This is a proposal on how to start handling resend webhooks with more detail over time. There is a simple mechanism for aggregate counting which might hit OCC if we get a bunch of bounces at once. Do we want to schedule an aggregator function instead of mutating them one at a time?