When I was doing some testing, I noticed this was returning with the literal string both in the diffing UI and in the rule forms, probably caused by the big i18n update that got merged in a couple weeks ago. This fixes the unicode to display correctly.

Should this actually be has_conflict: true? The test plan mentions that there should be a conflict, and I think it makes sense.

Let's say you have a rule with a customized field value, then the base version gets removed somehow. In such case I think we shouldn't automatically choose the target version, but force the user to make this choice.

Yeah I agree, I'll change the logic of what we're returning to match this output

I think this poses another question actually. Currently, whenever the base_version is missing, we assume the rule is not customized giving us the diff outcomes of StockValueNoUpdate for the -AA situation and StockValueCanUpdate for the -AB situation. Here is where that logic occurs in the code

Should we be instead assuming both are customized and the fallback for an undefined base_version would be to return the field and let users decide if they want to keep or update the field?

In this scenario we would return CustomizedValueSameUpdate for the now assumed -BB outcome and CustomizedValueCanUpdate for the -BC outcome.

The only downside I can think of for this would be we'd return all the fields for an entire rule no matter what if the base_version was unavailable which could be overwhelming.

cc: @banderror @nikitaindik

I think it's okay to return a bunch of fields in this edge case, since it should only happen once. Base version would get created if you upgrade a rule, right? Otherwise we run the risk of removing user's custom value with no way to return to it.

This was my line of thinking:
If we have the -AA situation this could mean one of:

• AAA -> no conflict, pick target
• ABB -> no conflict, pick target
  Since we don't know which case it is, we can assume the most complex scenario (ABB) and return ThreeWayDiffOutcome.CustomizedValueSameUpdate. Then indeed we'll return every field in response.

If we have the -AB situation this could mean one of:

• AAB -> no conflict, pick target
• ABC -> has conflict, user has to choose
  Again, I would assume the "worst" (ABC) and return CustomizedValueCanUpdate. Then the field would also have has_conflict: true and the user would have to make a choice.

I think we can merge this as is for now and wait until folks come back from vacations to discuss with them. Looking at the comment here, perhaps there was an idea behind the current behaviour 🤷 .

I have read the thread and agree with the compromise logic option. Does it make sense to inform the user about missing the base version when this happens?

@approksiu I think it's probably a good idea, not sure if that's in the UI plans yet or not

We'll discuss with @ARWNightingale.

Thanks for the feedback @approksiu, we'll go with option 3 then.

Does it make sense to inform the user about missing the base version when this happens?
not sure if that's in the UI plans yet or not

It would be a rare edge case to handle. It's not planned. I think it might be useful eventually, especially when we reach that 15k limit, but at this point I would not include this into Milestone 3. I opened a #186880 that we can consider adding to Milestone 4.

cc @dplumlee @jpdjere @xcrzx @nikitaindik

Agreed, definitely in Milestone 3. Thanks for adding the issue!

@nikitaindik @dplumlee This is a great catch, thank you both!

We have a technical and a UX sides of the question.

Technically, your above comments make sense that if we treat -AA as ABB and -AB as ABC, we would need to adjust the returned ThreeWayDiffOutcome values accordingly.

From the UX perspective, we have a trade-off:

• 1st option is to treat -AA as ABB and -AB as ABC. The trade-off is safety at the cost of usability. In practice, all -AA and -AB fields would be shown in the rule upgrade flyout, with -AB fields shown as conflicting. This might look confusing, dangerous and overwhelming, especially if the user has never customized their installed rules and just lost some of the prebuilt rule assets.
• 2nd option is to treat -AA as AAA and -AB as AAB. The trade-off is usability at the cost of safety. In practice, all -AA fields would not be shown in the rule upgrade flyout, and -AB fields would be shown in the flyout as auto-accepted, thus significantly saving the time to upgrade the rules. This might be dangerous for those rules that had been customized by the user, then Elastic published a new package with updates to those rules, and the user lost some of the prebuilt rule assets (-AB situation).

There can be a few ways to loose rule assets partially:

• By manually deleting some of them using a script, or dev tools, etc. I think chances are very low, and that would be the shooting yourself in the foot type of case.
• By installing a new package version where some of the historical rule versions will be missing. We have a hard limit of 15000 rule versions per package. We haven't reached it yet, but reaching it is a matter of time. When the TRaDE team reaches it, they will need to come up with an algorithm for evicting old rule versions from the package. Our upgrade logic should work well regardless of existence or non-existence of certain historical versions. What are the chances for the user to find themselves in this situation? I think it will depend on this eviction algorithm in the future, but currently I think it's 0.

The 1st option would be a fool-proof and safe way of handling the two situations above, the 2nd option would be a quick-and-easy way.

Probably there can be a 3rd, compromise option:

• Treat -AA as AAA and NO_CONFLICT for increased usability.
• Treat -AB as ABC and SOLVABLE_CONFLICT for safety. In this case, we would successfully auto-merge the change and return a merged_version: 'C', but mark it as SOLVABLE_CONFLICT according to the idea of solvable and non-solvable conflicts described in the RFC and this ticket. In this case, users would need to manually accept the auto-merged value in the upgrade flyout.

I agree that we should hold off changing the current logic until all people are back from vacations 👍