Repository navigation
YAML review: say when the resource changed after review - #1962
Conversation
An apply refused because the resource changed after review already re-runs the review against the latest version, but the screen kept only the red error, which reads as start over. When the refreshed review carries a newer resource version, a notice now says the diff shows the latest version and to apply again.
When the notice says the resource changed after review, the raw API message under it repeated the same thing; the error toast still carries it.
A retry that fails for another reason, and can't refresh the review, shows its own error instead of the previous attempt's notice.
PR Summary by QodoYAML review: notify when resource changed after review
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1.
|
A deleted resource refreshes with no version, and a cluster switch is its own error; neither shows the changed-after-review notice. A slower refresh from an earlier attempt no longer lands over a newer one.
Going back, starting over, or preparing another review now invalidates a refresh still in flight, so it can't restore an earlier draft for the next apply. Only the server's changed-after-review refusal gives way to the notice; a timeout or admission denial still shows beside it.
A reviewed apply's failure shows in the review (the changed-after-review notice, or the error itself), so the global 'Failed to update resource' toast repeated it. Errors from a reviewed apply are marked as shown inline and the mutation handler skips them; other saves still toast.
When you apply a reviewed YAML edit and someone else changed the resource after your review, the apply is refused with a 409. Radar already re-ran the review against the latest version. It didn't say so: the diff quietly changed under you, and the raw "resource changed after review" error sat beside it.
Now the review says it plainly: "This resource changed after your review. The diff above now shows its latest version. Check it, then apply again." The raw error is hidden while that notice shows, so there is one message, not two.
The notice shows only when the refreshed review is the same resource, on the same cluster, at a newer version. In every other case the attempt's own error shows:
A refresh that lands after you went back, cancelled, or prepared another review is dropped, so it can never restore an earlier draft for the next apply. Only the server's changed-after-review refusal gives way to the notice; a timeout or admission denial still shows beside it.
Verification
greeting, and review.kubectl.greetingand kubectl'sother.EditableYamlView.test.tsxcovers the flow end to end:YamlReview.test.tsxcovers the notice and the hidden raw error.client.updateResource.test.tsxruns the real query client: a reviewed apply raises no toast, and a save that isn't from a review does.make tscpasses. k8s-ui: 4136 tests pass; web: 1845 tests pass.A reviewed apply's failure no longer also raises the global "Failed to update resource" toast: the review shows it, so a toast would repeat it. Saves that don't come from a review still toast.