Currently we propagate labels from Route to Config/Revision in the core reconciliation loop; however, besides enforcing 1:N it is non-semantic.
This logic ends up being a significant # of LoC, and introduces potential reconciliation errors. For example, because we are cross-editing Configuration and Revision, we risk optimistic concurrency failures due to concurrent edits to these objects. This is papered over by the resync period, but given our sensitivity to performance we should have a very low tolerance for relying on resync for correctness.
I think we should consider splitting this into a separate reconciliation process, if possible.
Currently we propagate labels from Route to Config/Revision in the core reconciliation loop; however, besides enforcing 1:N it is non-semantic.
This logic ends up being a significant # of LoC, and introduces potential reconciliation errors. For example, because we are cross-editing Configuration and Revision, we risk optimistic concurrency failures due to concurrent edits to these objects. This is papered over by the resync period, but given our sensitivity to performance we should have a very low tolerance for relying on resync for correctness.
I think we should consider splitting this into a separate reconciliation process, if possible.