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 the code that handles the migration job throws (because of a bug), migrations are not marked as "executed", and the job ends.
When visited, migrations that don't have a job and are not marked as executed are started (in MigrationSheet).
But when an exception is thrown there, the page is refreshed, thus restarting the migration... which will probably stumble on the same exception, thus restarting again.
I suggest converting the "executed" boolean flag to a number that describes the current state:
0: not executed
1: executed
2: executing
3: canceled
4: errored
and only start a migration if executed = 0. I would do it differently from the start, but only slightly and this way is backward compatible with existing migration pages.
When the code that handles the migration job throws (because of a bug), migrations are not marked as "executed", and the job ends.
When visited, migrations that don't have a job and are not marked as executed are started (in MigrationSheet).
But when an exception is thrown there, the page is refreshed, thus restarting the migration... which will probably stumble on the same exception, thus restarting again.
I suggest converting the "executed" boolean flag to a number that describes the current state:
and only start a migration if executed = 0. I would do it differently from the start, but only slightly and this way is backward compatible with existing migration pages.
3 (Canceled) is useful to fix #45
2 and no job means the job died, so this is an error.
The text was updated successfully, but these errors were encountered: