You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. 💡
The text was updated successfully, but these errors were encountered:
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. 💡The text was updated successfully, but these errors were encountered: