affandar

You are creating a durable function and starting its execution at the same time by calling df.start(<durable function definition>). This will you give you back an instance id which represents this durable function execution. You can use this to refer to this execution from this point onwards.

Within this durable function you are calling df.wait_for_signal(<signal_name>). This call is exactly once within this function instance. There are no duplicates possible. Your df.start() call might get duplicated if it times out and you re-run it, but in this case it would end up creating a different function instance.

Any 'unhandled' errors in executing SQL will fail the function instance. Its status would bubble up the exact error being raised.

(Author of both durable task framework and pg_durable/duroxide here)

Indeed Durable tasks is an exceptional project and was a unique innovation at the time.

pg_durable brings the same reliability and durablity semantics to long running operations within the database.

We have tons of interesting scenarios on the roadmap. Stay tuned! :)

(pg_durable committer here)

The provider is an extensibility point. We just shipped the simplest version of it. Happy to take contribs if someone sends a pgmq based provider!

(Disclosure: I'm from Azure's Postgres team)

Clarification: OpenAI does not self-host Postgres. They use Azure's managed PostgreSQL offering (aka Azure Database for PostgreSQL Flexible server).