The WhereToRunSection probe effect depended on the whole run draft, so
every keystroke in a provider config field re-fired the effect, re-probed
the provider binary, and — because each probe result is a fresh object —
kept re-probing in a loop for as long as the dialog sat on a provider.
Each resolution then reset providerConfig to schema defaults, erasing
whatever the user had typed. Fields without a schema default (the
Kubernetes 'Kubeconfig context') read as completely dead.
Fix:
- Probe once per provider selection, keyed on the provider's stable
binary path — not the draft, not the provider object (a providers-query
refresh must not reprobe an unchanged selection).
- Resolve with latest-state semantics via useEffectEvent + a new
applyProbeResult helper that merges schema defaults BENEATH the current
providerConfig, so a probe landing after the user typed can never
clobber in-flight input.
Tests:
- unit: applyProbeResult merge semantics (defaults under typed values,
user-cleared fields stay cleared, schema-less results).
- e2e (new where-to-run-config.spec.ts, red-first verified against the
unfixed component): typing sticks + exactly one probe per selection,
probe-gated form render with a slow probe, provider->local->provider
reset. Mock bridge gains backendProviders / backendProviderProbeResult /
backendProviderProbeDelayMs seams.
Reported by Tyler in buzz-remote-agents (channel 29414326, thread
db76677a): could not type into the Kubeconfig context field.
Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d
8eb7680795