Use primary DB connection for advanced search bulk indexer

Terri Churequested to merge
fix/elastic-bulk-cron-use-primary into master

What does this MR do and why?

Changes ElasticIndexBulkCronWorker from data_consistency :sticky to data_consistency :always so the advanced search bulk indexer reads from primary.

:sticky only protects against replica lag when the Sidekiq job is enqueued from a session that just wrote — the client middleware captures primary_write_location only when SessionMap.current(lb).use_primary? is true (see wal_tracking_sender.rb:17-26).

The chain that produces refs for this worker is:

after_commit -> Elastic::ProcessBookkeepingService.track! -> Redis ZADD
... cron tick fires ElasticIndexBulkCronWorker
... schedule_shards -> self.class.perform_async(shard_number)
... shard worker reads WorkItem.id_in(ids) for the popped refs

The shard perform_async runs inside the cron parent job's session, which only reads (settings, lease, ES health). No primary write has happened, so the client middleware stamps the replica's own current LSN. The server middleware then trivially considers replicas "in sync" and routes the shard worker to a replica with no catch-up requirement.

Result: when the replica is behind the milestone (or any other) write that triggered the enqueue, the shard worker reads the pre-commit row, writes that stale state to Elasticsearch, and removes the reference. The index stays stale until the next write to that record.

The other two Elastic::BulkCronWorker includers — ElasticIndexInitialBulkCronWorker and Search::ElasticRetryQueueCronWorker — stay on :sticky. See the issue for the reasoning.

References

How to set up and validate locally

  1. With Elasticsearch indexing enabled in GDK, edit a work item / issue / merge request.
  2. Observe the track_items log emitted from Elastic::ProcessBookkeepingService.track! (debug level) and the subsequent indexing_done log from ElasticIndexBulkCronWorker.
  3. Verify the worker now runs against the primary DB connection (the json.load_balancing_strategy field on the indexing_done log line should be primary rather than replica).

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports