mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d
8eb7680795
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>