johtso

It’s impossible to know whether an action completed successfully if an error occurs between sending the request and persisting the result

Sure, but this is not a protocol, this is an API. APIs that allow actions that cost money, potentially annoy users / effect your reputation in the eyes of email recipients, I believe, should allow the caller to supply a unique key to enforce idempotency.

Another email sending service without support for idempotency?

Yes this behaviour is infuriating, the surprise autocorrect! Can result in some really embarrassing messages being sent..

This is the trouble with common names, the way to avoid ambiguity is to use the binomial name.

When you're having to work with someone else's godawful convoluted database schema you're sometimes really happy not to have to write the query yourself. Giving the LLM context with previously written queries can be quite effective.

The writing SQL experience is a product of both SQL's syntax, the structure of the database you're querying over and the complexity of your query.

When things get hairy, and you have a good number of representative queries already written that you can use as context, LLMs can be really nice tool.

This is fairly common with linting/test coverage tools

I've been having a bad time with email of late. It's been the method of communication between us and another company (a pretty creaky old product). I thought they were replying strangely and ignoring my questions "did they even read what I said!?". It turns out for whatever reason they hadn't been getting some of my emails.

Now I can't trust that anything has been received unless I get an acknowledgement, so I have to keep pestering for replies. Basically lost trust in the protocol because it's dependent on the the other person's mailserver behaving they way you expect it to.

sqlc always seemed like a really neat concept to me. I love the idea of being able to write my queries as raw SQL in separate files, would make everything so much more interoperable with other tools. Having your queries defined as strings inside some other programming language always struck me as not so awesome.

I'd love to see something like this for Typescript and Effect's SQL integration with schemas.

Maybe, depending on where you are in the world, you could make some kind of GDPR request to get access to your data, even if you don't recover your account?

Thanks for recommending mailpace, £7.50/month for 10,000 emails is very reasonable, _and_ they support idempotency! Definitely makes me consider switching to them..

Please tell me this supports some kind of idempotency.. I fear it wont.

The kind of hoops I've had to jump through to achieve DIY idempotency with Postmark would make you cringe, a shared lock to avoid race conditions, and then using the API to check if an email with the unique id (manually added to the metadata when sending) has not already been sent before sending an email.

Being safe in the knowledge that an email with some unique key will only be delivered once regardless of bugs, processes dying mid task, network issues etc. just makes life so much simpler. The risk of sending duplicate emails or at worst spamming your users due to some more nefarious bug is something that you really want to guard against at as low a level as possible. Sure this might not be quite as consequential as duplicate charges through the Stripe API for example (Stripe have always seemed to lead the way with good API design in this regard).. doThing(data) is _not_ good enough for executing tasks over a network that are effectful, have a cost, and potentially risk your reputation if things go wrong. Idempotency keys should far more widely supported!

Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?