When a migration fails on the first batch, it returns the failure but doesn't persist the failure to the database.
This can be confusing when it wasn't started directly by a user, as the failure isn't apparent when you ask for the status - it's either not there, or showing results from a previous run.
The tradeoff is that we could always persist the start of a migration but do no work in the first mutation, but then when you run it directly you won't see the immediate failure (because it will happen in a scheduled function).
I currently think it's more helpful to see the failure of the first batch, at the cost of not having a record of it.
Why not fail and persist?
We could catch the failure and then persist, but catching the failure doesn't roll back the failure's changes.
Potential workaround: we could use runMutation to run a sub-transaction that could fail and roll back, but the outer transaction can catch that and persist the failure, without accidentally committing the sub-transaction's changes. 💡
When a migration fails on the first batch, it returns the failure but doesn't persist the failure to the database.
This can be confusing when it wasn't started directly by a user, as the failure isn't apparent when you ask for the status - it's either not there, or showing results from a previous run.
The tradeoff is that we could always persist the start of a migration but do no work in the first mutation, but then when you run it directly you won't see the immediate failure (because it will happen in a scheduled function).
I currently think it's more helpful to see the failure of the first batch, at the cost of not having a record of it.
Why not fail and persist?
We could catch the failure and then persist, but catching the failure doesn't roll back the failure's changes.
Potential workaround: we could use
runMutationto run a sub-transaction that could fail and roll back, but the outer transaction can catch that and persist the failure, without accidentally committing the sub-transaction's changes. 💡