[Security Solution] Auto-merge ignores incoming rule changes for rule query fields

[xcrzx]

Summary

When rule customization is enabled, during a rule upgrade, incoming changes to a field are ignored if the same field has been modified in the current version.

Steps to Reproduce

1. Enable rule customization.
2. Find a rule with an update to a multiline string field (e.g., ESQL).
3. Make a local change to the field (e.g., modify any line).
4. Open the update flyout to review the rule update.

Expected Result

The merge algorithm should respect incoming changes for the rule field. The proposed version should include both local and remote changes. For example:

• The target version includes a new line added to the query.
• The current version has a different line modified.

There’s no actual conflict, as different lines were touched. Both edits should be preset in the final version:

Actual Result

The change introduced by Elastic is missing in the final version:

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[maximpn]

This ticket was discussed at out product meeting and it was decided to make the following in Milestone 3 scope

• Change field with conflicts header's text to make it explicit users have to merge current value with Elastic update manually
  

• Show Update from Elastic Diff view by default

---

Solution for Milestone 4 would require more elaborated approach. Rule query diff algorithm should be changed to merge rule query changes made by users with update from Elastic. In general case it might be really tricky when changes are made to the same lines. It'd require producing AST Trees and merging them together. We should start with a simpler option merging changes made to different lines. Though result query may be invalid. We can run query validation to make sure the result query is valid. In case the algorithm is unable to merge or the result query is incorrect it should fallback to the current value.

As a potential pitfall such changes may cause performance degradation. It should be verified such changes won't reduce _review API endpoint performance.