Kai Schlamp

Ok, good point. I will give it a try.

> So shall I close this as #1224 was merged or do we keep it open for the replacement of sync_to_async ? PR #1226 will close it :-)

In some cases, it could simplify the abortion process and save the user some code (e.g., no need for another asyncio task that monitors the abort status). On the other...

I also tried to contact @joke2k Unfortunately, I also have not received an answer. I hope he is well (but at least he does some non public commits). The good...

I can also confirm that #1114 is the way to go, which explicitly states what the public interface is. Otherwise, it breaks all `pyright` type checking, as implicit private imports...

@ewjoachim, in our session, I think we made a wrong assumption regarding function renaming. Function bodies are stored as strings, so when a function is renamed and used by another...

> Awesome work :) I'm still trying to find some time to test this with v2 & v3 with only pre. Life is a bit hectic at the moment so...

@ewjoachim Unfortunately, I have difficulty checking if the pre-migration runs with even v3. For testing purposes, I deleted the post-migration, ran all migrations on an empty database, and dumped the...

I am not sure if it is as easy as this, or whether we should ignore the failing test (which is done for new migrations, not for retrospectively added ones).

I wonder a bit why this wasn't caught by our tests. Shouldn't [`run_migrations`](https://github.com/procrastinate-org/procrastinate/blob/58b44e733e133f9a7dead14f74fe631ff825d639/tests/migration/test_migration.py#L34) have failed on 03.00.00_50_post_cancel_notification.sql as it renames an index that isn't there? And shoudn't `migra` detect the...