Strategy on sync name conflict

[jakubdyszkiewicz]

Description

When we apply policies on global and zone, we hash them so it's very unlikely that we get into name conflicts. However, it's still possible with the following steps

1. Apply object on global named xyz, see that synced name in zone is xyz-hashname
2. I delete object on global
3. I apply object on zone with name xyz-hashname. It’s synced to global but that does not matter here
4. I apply the same object on global named xyz

Let see what happens. We need to have a defined strategy for such case.

[jakubdyszkiewicz]

Triage: needs-reproducing to figure out what happens now

[Automaat]

Applying steps from issue description ends with error on zone:

2024-05-17T08:28:55.172Z    INFO    kds-delta-zone    creating a new resource from upstream    {"type": "MeshTimeout", "name": "mesh-timeout-all-default-bv8z44b7bzb99xc7.kong-mesh-system", "mesh": "default"}
2024-05-17T08:28:55.292Z    INFO    kds-delta-zone    error during callback received, sending NACK    {"kds-version": "v2", "err": "resource already exists: type=\"MeshTimeout\" name=\"mesh-timeout-all-default-bv8z44b7bzb99xc7.kong-mesh-system\" mesh=\"default\""}

It would be nice to add status to policy with this error on global

[jakubdyszkiewicz]

Triage: rejection is fine. It would be great to bubble up this error better than logs.