Enabling/disabling bindings does not always trigger a specification update

Bug

The Next button is not always presented after one or more bindings have been enabled/disabled. This behavior is independent of the method used to enable/disable the bindings (i.e., the mass action menu and the binding-level switch). Given the interface will appear as anticipated, it is hard to know whether a switch is staged or reflects the current state of the binding.

This can result in a publication failure since capture bindings that appear to be disabled in the client will reference collections that are pruned by the client. For more insight as to why and when disabled collections are pruned from a draft, see issue 1183.

Reproduction Steps

Pending.

Expected

The Next button should always be presented after at least one binding has been enabled/disabled.

Screenshots

N/A

Desktop

OS: Windows
Browser: Chrome (Version 127.0.6533.120)

Additional Context

Issue 1049 reports similar behavior; the client is occasionally not properly detecting that its understanding of the draft has diverged from that of the server. If there is a way to reliably reproduce the current issue, then the linked issue deserves a follow-up.

estuary / ui