Hugo

Promise.all over 2,400 sends is 2,400 concurrent requests, so you did not hit the limit halfway, you hit it immediately and 600 happened to squeak through before the bucket emptied. The default is around 2 requests a second on most plans.

Two changes. Use the batch endpoint instead of one call per recipient, it takes up to 100 messages per request, so 2,400 people is 24 calls, not 2,400. And write the send state before you send, not after:

UPDATE subscribers SET state='claimed', batch_id=$1
WHERE id = ANY($2) AND state='pending'
RETURNING id

Only send the rows that come back from the RETURNING. Now the process can die anywhere and a re-run picks up exactly what is left, and nobody gets two copies.

10 a second is five times over the default, so that loop 429s too, just more politely. If you insist on sequential the sleep has to be 500ms and you are looking at 20 minutes for the list. The batch endpoint is strictly better and it is one line of difference.

const versus property, not sync versus async. I had built an entirely wrong mental model around timing and it explains three other places this has bitten me.

Third option nobody proposes because it feels like giving up: three functions. query, queryOne, queryStream. No type machinery at all, better autocomplete, greppable, and the streaming one can have a completely different signature when you inevitably need a batch size argument.

The urge to make one function do three things is where most of this category of pain starts.

Power save on the wifi chip. Check it with iw dev wlan0 get power_save and I would bet money it says on.

Turning it off with iw dev wlan0 set power_save off will confirm the diagnosis within an evening, but that does not survive a reboot. Make it stick with a tiny systemd unit that runs the same command after the network is up, or if you are on NetworkManager set wifi.powersave = 2 in a file under /etc/NetworkManager/conf.d/.

The reason it looks like the Pi died is that the chip goes into a deep sleep and then fails to wake for beacons, so the router quietly ages it out of the association table. Nothing on the Pi notices because nothing on the Pi was trying to talk.

One gotcha on USB boot: if the Pi has been sitting untouched since 2019 you need to update the EEPROM first with sudo rpi-eeprom-update -a while it can still boot from the card. Do that before you wipe anything, otherwise you get a green light and no HDMI output and spend an evening confused.

The hover tooltip thing catches everyone. If you want readable hovers on any derived type:

type Pretty<T> = { [K in keyof T]: T[K] } & {}

Wrap and the tooltip flattens. Changes nothing at runtime and nothing about assignability, it just makes the editor tell you the truth in a readable way.

One thing nobody mentions: HDMI plus a drive plus a keyboard is a very different load from the headless setup you probably intend to run. If this ends up as a headless box on a shelf, unplug the monitor and retest before buying anything. Mine only complained during setup and has been clean for a year since.