chore: refactor notifications send in batch

[mariojsnunes]

PR Checklist

• - Unit and/or e2e tests for the changes that have been added (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Refactoring (no functional changes)

What is the new behavior?

Emails are sent in batches of 100.
This should solve some emails not being sent due to hitting resend limits.

The new approach brings the resend code to our server, instead of using the edge function.

Does this PR introduce a DB Schema Change or Migration?

• Yes

Git Issues

Closes #

[cypress]

onearmy-community-platform    Run #8447

Run Properties:   Failed #8447  •  34ad9d5149: fix a few cy tests

Project	onearmy-community-platform
Branch Review	feat/refactor-notifications-batch
Run status	Failed #8447
Run duration	10m 05s
Commit	34ad9d5149: fix a few cy tests
Committer	Mário Nunes
View all properties for this run ↗︎

---

Test results
Failures	1
Flaky	1
Pending	0
Skipped	0
Passing	93
View all changes introduced in this branch ↗︎

---

Tests for review

  src/integration/research/read.spec.ts • 1 failed test • ci-chrome

View Output Video

Test		Artifacts
... > [Visible to everyone]		Test Replay Screenshots Video

  src/integration/settings.spec.ts • 1 flaky test • ci-chrome

View Output Video

Test		Artifacts
[Settings] > Can create member		Test Replay Screenshots Video

[benfurber]

Aren't these auth focused?

[mariojsnunes]

They are not being used as far as I can see.

[benfurber]

Looking good.

My worry about the responsibility of the SQL function current is that it's hard to follow. Can't the validating the user email preferences stay a TS service focused?

(I'm sure it's on your list already but looks like a bunch of code can be removed from the edge function folder.)

[mariojsnunes]

My worry about the responsibility of the SQL function current is that it's hard to follow. Can't the validating the user email preferences stay a TS service focused?

Before we were doing 1 query per user (and was still an sql function because needs access to auth.users).
Could split the query into 2:

• Get the subscribers profileIds
• Get emails corresponding to those profileIds

But I don't see a benefit to that, the 2nd query especially would be longer: select email from x where profile_id IN ({all profile ids, which could be hundreds})

But I'll look into making it more readable.