Add routing field to issues index
What does this MR do and why?
We are introducing a new operation type for indexing into Elasticsearch called :upsert. It does the same as :index except for one small nuance:
When a document with the same id exists in the index and the document source is not updated but the routing is changed, the operation does not update the document's routing (i.e. create a new document).
Other cases are the same as for indexing: If the document does not exist, it creates with the correct routing; if the routing is changed and the document source is changed, a new document is created with the correct routing.
A solution is to always make sure the document source updates when routing is changed. For our current document types this is always the case because routing depends on either project_id or namespace_id which are present in the document source. However, to prevent this nuance being overlooked, we will add a routing field to the document source that is equal to the document's routing value.
If an upsert operation is used and routing is not defined, we will send an error to Sentry.
I don't think an immediate backfill migration is needed as this field is needed for upserting specifically and there might be a backfill migration for issue embeddings soon in any case.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
How to set up and validate locally
- Execute migration worker:
Elastic::MigrationWorker.new.perform - View the issues mapping and ensure the routing field is present.
- Index a document:
Elastic::ProcessBookkeepingService.track!(Issue.first);Elastic::ProcessBookkeepingService.new.execute - Ensure the routing field is populated with the same value as its routing.
Related to #454249 (closed)