We allow migrations to mark schema IDs as modified to later trigger
the "post-migration" event for them. We used to store that set in
memory only. This potentially led to lost post-migration events when
e.g. etcd was unavailable at the time of applying migrations or one of
the event handlers failed. Another run of "migrate up" did not mark
the same schemas again, because db migrations were already applied and
thus not executed. It was also easy to miss the fact that
post-migration events were not triggered.
This commit introduces an additional db store for the modified schema
set. This way, if gohan can't handle all post-migration events,
remaining ones will be loaded from the database on next try. Pending
post-migration events also block running gohan server in no_init
mode, this mirrors the behavior of pending migrations. It makes it
also impossible to unintentionally ignore.
Newly introduced behavior is compatible with forced post-migration
events. If a forced schema happens to have a pending post-migration
event, it will be treated as completed, provided the event handler
succeded. If one forces 2 out of 3 pending schemas, the remaining one
will still block execution of gohan server.
We allow migrations to mark schema IDs as modified to later trigger the "post-migration" event for them. We used to store that set in memory only. This potentially led to lost post-migration events when e.g. etcd was unavailable at the time of applying migrations or one of the event handlers failed. Another run of "migrate up" did not mark the same schemas again, because db migrations were already applied and thus not executed. It was also easy to miss the fact that post-migration events were not triggered.
This commit introduces an additional db store for the modified schema set. This way, if gohan can't handle all post-migration events, remaining ones will be loaded from the database on next try. Pending post-migration events also block running
gohan serverinno_initmode, this mirrors the behavior of pending migrations. It makes it also impossible to unintentionally ignore.Newly introduced behavior is compatible with forced post-migration events. If a forced schema happens to have a pending post-migration event, it will be treated as completed, provided the event handler succeded. If one forces 2 out of 3 pending schemas, the remaining one will still block execution of
gohan server.