To avoid quiet failures that cause consistency errors in the database,
we should now assume that the internal_ids table is available since
we've had this table for close to a year.
For tests that have migrations, we make this check thread-safe via
SafeRequestStore.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/60718
If no pipeline is created we currently have IID gap.
This is due to fact that we generate IID not on save,
but rather ahead of time. This results, us,
losing IIDs.
After the import has finished, we flush (delete) the InternalId records
related to the project at hand. This means we're starting over with
tracking correct internal id values, a new record will be created
automatically when the next internal id is generated.
The GitHub importer assigns iid values by using supplied values from
GitHub. We skip tracking internal id values during the import in favor
of higher concurrency. Deleting any InternalId records after the import
has finished is an extra measure to guarantee consistency.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54270.
This is useful for a transition period to migrate away from
`NoninternalAtomicId`. In a situation where both the old and new code to
generate a iid value is run at the same time (for example, during a
deploy different nodes may serve both versions), this will lead to
problems regarding the correct `last_value`. That is, what we track in
`InternalId` may get out of sync with the maximum iid present for
issues.
With this change, we double-check that and correct the `last_value` with
the maximum iid found in issues if necessary.
This is subject to be removed with the 10.8 release and tracked over
here: https://gitlab.com/gitlab-org/gitlab-ce/issues/45389Closes#45269.
GitLab Bot