Yeah, just... like, don't use ctx from WithContext after the errgroup. WithContext is an API that specifically and explicitly cancels the context on error. It's absolutely optional. It's not a bug at all. It's using the wrong APIs and using a variable out of intended scope.
Anything that guarantees exactly once is selling snake oil. Side effects happen inside any transaction, and only when it commits (checkpoints) are the side effects safe.
Want to send an email, but the app crashes before committing? Now you're at-least-once.
You can compress the window that causes at-least-once semantics, but it's always there. For this reason, this blog post oversells the capabilities of these types of systems as a whole. DBOS (and Inngest, see the disclaimer below) try to get as close to exactly once as possible, but the risk always exists, which is why you should always try to use idempotency in external API requests if they support it. Defense in layers.
Disclaimer: I built the original `step.run` APIs at https://www.inngest.com, which offers similar things on any platform... without being tied to DB transactions.
As the post says, the exactly-once guarantee is ONLY for steps performing database operations. For those, you actually can get an exactly-once guarantee by running the database operations in the same Postgres transaction as your durable checkpoint. That's a pretty cool benefit of building workflows on Postgres! Of course, if there are side effects outside the database, those happen at-least-once.
You can totally leverage postgres transactions to give someone... postgres transactions!
I just figured that the exactly once semantics were so worth discussing that any external side effects (which is what orchestration is for) aren't included in that, which is a big caveat.
> Anything that guarantees exactly once is selling snake oil.
That's a pretty spicy take. I'll agree that exactly-once is hard, but it's not impossible. Obviously there are caveats, but the beauty of DBOS using Postgres as the method of coordination instead of the an external server (like Temporal or Inngest) is that the exactly-once guarantees of Postgres can carry over to the application. Especially so if you're using that same Postgres to store your application data.
Inngest (https://www.inngest.com) | Engineers, Marketing+GTM | Remote (US, San Francisco) | Full-time | $130-245k + equity Inngest is a developer platform that enables developers to build amazing, complex, and reliable products without the hassle of building and maintaining infrastructure. It combines modern orchestration, advanced multi-tenant aware queueing, and built-in observability packaged in an easy to learn and use product that any developer can learn.
We're backed by top tier investors including a16z, Notable Capital, Afore capital and angels including Guillermo Rauch (Vercel) and Tom Preston-Werner (Github co-founder). We serve customers from startups and large co's like Resend, SoundCloud, Gumroad, TripAdvisor, Browser Use.
You: Want to be part of a fast growing startup that is changing how developers build software.
- Distributed Systems, Execution Engineer - San Francisco
- Product Engineer - Full Stack - San Francisco, Remote US
In the partnership model Waymo charges uber for the ride and Uber charges the customer.
The interesting thing is that uber loses money on every ride. Waymo charges Uber more than Uber charges the customer.
On Uber’s side, though, this is preferable to losing the entire ride. Uber loses much more slowly by controlling the distribution and losing a few dollars per ride than by losing the entire customer base with no revenue from these customers.
AFAIK, it's due to things like single frame construction and expensive + backlogged parts which you order directly from Tesla (as opposed to, eg, a drivetrain that may be made for 3 separate manufacturers).
Or, when you do have an accident it's typically more expensive to repair.
There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.
Promoting it? No problem. But promoting something you profited from without disclosing it violates FCC rules for broadcasting. I would say influencers aren't technically broadcasting but they are in principle.
