[dawsontoth]

Closes #1800

Stacked on #1802, which is stacked on #1801: #1801 → #1802 → this PR → #1846 (#1686). Its base is claude/1630-challenge-cert-poll-backoff, so this diff is only the Bind-selection change. Review and merge #1801 and #1802 first.

⊙ Problem

On a cluster's Domains page, the domains ticked for binding are page state that outlived their rows. Tick a domain, then click Remove Domain on it (enabled for any unbound domain, ticked or not): the row disappears, but Bind 1 Domain stays, and clicking it sends the deleted id. Central manager answers 404 Domain <id> not found, and since the selection only clears when a bind succeeds, every later Bind on that page fails the same way until the user leaves it. A ticked domain that gets bound to another cluster meanwhile fails the same way with a 400 (#1800).

❓ Your call: does this need to ship on its own? #1846, the #1686 PR stacked on this one, re-reads the domain list before every domain change and would refuse the stale id with a message. I kept this separate because it needs no extra request, and it fixes what the button counts and sends, which a refusal alone doesn't.

💡 Solution

Bind now counts and sends only the ticked domains that the current list still offers for binding: the selection intersected with the rows canBindDomain accepts, which is the same predicate that renders the checkbox. A domain that was removed, or bound elsewhere, drops out of the count and the request on its own, with no extra state to keep in sync.

Three gaps around a removal are closed as well:

• the deleted row leaves the cached domain list as soon as the delete succeeds, not when the refetch lands, so a Bind in between can't send it;
• Bind is disabled while a removal is in flight, and Remove while a Bind is; a click queued before that re-render is refused either way (Bind, Remove), so a PUT and a DELETE for the same domain can't race;
• Bind reads the list from the query client when clicked, not from the render, because a cache change reaches the button a render later.

⚖️ Alternatives

• Prune the selection when the list changes (an effect, or deselect on delete): it is a second copy of the same predicate kept in sync by hand, and it misses a domain that becomes bound elsewhere in a refetch, which no delete callback sees.
• Disable Remove Domain on a ticked row: it covers the delete but not a domain bound from another tab, and blocks a removal the user is entitled to make.

🔧 Changes

• Management.tsx: the Bind button's count and visibility come from domainIdsToBind; the click handler refuses while a delete is in flight and recomputes the ids from the query client, and Bind is disabled meanwhile.
• canBindDomain.ts (new): the bindable-row predicate, now shared by the checkbox and Bind, and bindableDomainIds, the selection filtered by it.
• tableDefinition.tsx: the checkbox uses canBindDomain; Remove refuses while a domain change is in flight; the delete call passes the organization id the cache write needs.
• deleteDomain.ts: the mutation takes a mutation key, removes the deleted row from the cached list on success, and exports isDeletingDomain / useIsDeletingDomain.
• Both files' success invalidations (Bind, Remove, Unbind) go through the same useQueryClient() the guards read, and the module-level queryClient import is gone. Production provides that same instance, so this changes nothing at runtime, but a test's own client now sees the refetch.
• setDomainIdsOnCluster.ts: exports isSettingDomainIds, the synchronous check mutateWhenIdle already made, so Remove can share it.
• src/features/cluster/DESIGN.md, DESIGN.md: a note on the Bind selection and the index line.

✅ Verification

End-to-end route: not observable end-to-end here — it needs a cluster, verified custom domains and a central manager, and a Bind changes real infrastructure. Verified at the request boundary instead: Management.test.tsx renders the real DomainsManagement and table against a mocked apiClient and asserts the serialized PUT body.

• Management.test.tsx, new "a ticked domain the list no longer offers" block:
  • a removed ticked domain is not sent, even while the list refetch never lands (only the cache write can drop it);
  • a ticked domain the refreshed list shows bound to another cluster is no longer offered;
  • Bind is held while a removal is in flight;
  • a Bind click queued behind a removal is refused, and a Remove click queued behind a Bind;
  • a click that lands after the list changed but before the button re-rendered sends only what the list still offers.
• Management.test.tsx, new "refetches the domain list through the page's own query client" block: once a bind, an unbind or a removal lands, the list is fetched again on the test's client. Fetches are counted from when the request goes out, so A refused domain change or cluster edit explains why on the page, and Studio checks a domain change before sending it #1846's pre-send read can't satisfy it. All three went red with the global client restored, and again with the invalidations removed, here and on A refused domain change or cluster edit explains why on the page, and Studio checks a domain change before sending it #1846's code.
• canBindDomain.test.ts (new): verified + unbound is offered; pending, bound (to any cluster) and self-managed are not; bindableDomainIds keeps tick order and offers nothing before the list loads.
• Fails on base: all six new Management.test.tsx tests fail against the origin/claude/1630-challenge-cert-poll-backoff sources with the bug signatures (the label stays Bind 2 Domains after a removal; the button stays for a domain bound elsewhere; Bind stays enabled during a removal; the queued Remove sends its DELETE; the render-lag click sends both ids). Each guard was mutation-checked: without the cache write, the intersection, the disabled state, either queued-click guard or the click-time read, its test goes red.
• Gates (Node 24.21.0): npx vitest run 397 files / 3,688 passed (exit 0), npx tsc -b exit 0, npx oxlint --format stylish . exit 0, npx dprint check exit 0, and again by the pre-commit hook. At 594707c the pre-commit hook ran 397 files / 3,691 passed, and npx tsc -b, oxlint and dprint check exited 0.

Pre-push review: three full rounds (codex graded, gemini). The Harper-domain adjudicator failed on auth every round and the Cursor legs failed on the 1Password SSH agent, so no round converged. Round 1 found the render-lag click (fixed: Bind reads the list from the query client); round 2 found the reverse race, a Remove queued behind a Bind (fixed: Remove shares isSettingDomainIds). Round 3 returned COMMENTS with no defects. I rejected:

• "other useDeleteDomain callers break on the new organizationId" (gemini): tableDefinition.tsx is the only caller, and DeleteDomainSchema is only a type;
• "a double-clicked Bind sends two PUTs" (gemini): Unbinding one custom domain no longer turns off certificates for the others #1801's mutateWhenIdle already refuses a second domain change while one is in flight;
• the remaining comment nits (both legs): the two kept comments state why the handlers read the query client rather than the render, and why the delete writes the cache, neither of which the code says.

A fourth full round at 3740ab4 (codex graded, gemini, Harper domain adjudicator, all ok) raised nothing against the query-client change. Its one surviving minor predates this PR. After a Bind's PUT settles, the domain row has no clusterId until the [orgId] refetch lands, so for that round trip Remove is enabled on a domain the cluster now holds. Central manager refuses that DELETE with a 400, "Domain is currently assigned to a cluster. Please remove the domain from the cluster first." (src/resources/domain/Domain.js:124-129 in central-manager). It writes the domain's clusterId before the PUT answers (updateCluster.js:194), so the delete cannot land and leave a dangling id. The adjudicator's other surviving notes were a one-tick stale closure in Unbind (also predates this PR), the comment nits above, and extensionless imports (the repo's convention).

❓ Your call: close that Remove-after-Bind window here, by writing the bound domains' clusterId into the cached list on success the way a delete removes its row, or leave it to central manager's refusal? I left it, because the refusal is accurate and #1846 rebuilds this mutation.

❓ Your call: two smaller choices from the same round. A Bind or Remove refused by a guard returns silently. That only happens when a click lands in the render between another change starting and the controls disabling, so a toast would mostly be explaining a double-click. And the guards are two mutation keys that check each other, not one shared domain-change key. One key would be simpler to reason about, at the cost of re-keying #1801's useIsSettingDomainIds.

gemini-code-assist feedback: both comments, "invalidate through activeQueryClient, not the global import", were right in substance: no runtime effect, but a test's client never saw the refetch. Fixed in 3740ab4, and the tests were tightened in 594707c.

_{🤖 Generated with Claude Code (Claude Opus 5.5); posted via @dawsontoth.}

Related PRs: #1801 overlaps (this PR stacks on it), #1802 overlaps (this PR's base), #1846 overlaps (stacked on this PR; it rebuilds the same domain-change handlers), 2 others independent
Complexity: easy

_{Review-Coverage: authored=claude; ran=gemini,codex; adjudicated=domain; blocked=cursor-composer(no-receipt),cursor-muse(no-receipt); declined=cursor-grok,cursor-kimi; rounds=4; full=1 @ 594707c}

_{Review-Attention: read ~4m (decisions: settle-before-refetch, per-mutation-guards, silent-refusal, do-less-alternative) @ 594707c}

[gemini-code-assist]

Code Review

This pull request improves the domain binding and removal flow in the cluster domains management feature by handling race conditions between concurrent bind and delete actions. It introduces state checks to ensure only bindable domains are processed, disables controls while mutations are in flight, and optimistically updates the React Query cache upon domain deletion. The review feedback correctly points out that the global queryClient is still being used for query invalidation in Management.tsx and tableDefinition.tsx instead of the newly introduced activeQueryClient hook, which could lead to issues in test environments or custom configurations.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	71.24%	11413 / 16020
🔵	Statements	71.36%	12166 / 17048
🔵	Functions	65.75%	3014 / 4584
🔵	Branches	66.71%	8893 / 13329

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/features/cluster/domains/Management.tsx	78.02%	84.21%	82.35%	79.31%	88, 114, 117-118, 210-236, 244, 250-251
src/features/cluster/domains/canBindDomain.ts	100%	100%	100%	100%
src/features/cluster/domains/constants/tableDefinition.tsx	93.33%	83.87%	93.33%	95.34%	141, 174, 187
src/features/clusters/hooks/useUpdateCluster.ts	0%	100%	0%	0%	12-23
src/features/clusters/mutations/setDomainIdsOnCluster.ts	100%	100%	100%	100%
src/features/clusters/upsert/ClusterBilling.tsx	0%	0%	0%	0%	33-134
src/features/clusters/upsert/ClusterDetails.tsx	0%	0%	0%	0%	62-260
src/features/clusters/upsert/ClusterForm.tsx	0%	0%	0%	0%	72-590
src/features/organization/mutations/deleteDomain.ts	100%	100%	100%	100%
src/features/organization/queries/getOrganizationDomains.ts	100%	100%	100%	100%

Generated in workflow #2247 for commit e1c66ca by the Vitest Coverage Report Action