Sticks to the primary if no location provided
What does this MR do?
In case when database_write_location or database_replica_location are not provided to SidekiqServerMiddleware, we will fall back to the primary database.
It can happen during the rollout of the data_consistency feature flag, that some jobs are already scheduled and that database_write_location or database_replica_location will not be provided. This can cause us to read from a stale replica that has not caught up with the latest changes.
The changelog is not required, since we currently have only single worker that utilize this feature, and it's behind the feature flag.
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because no workers have the feature flag enabled, so this is not user facing.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Related to #329183 (closed)