fix(errors): say a write's outcome is unknown when it got no verdict, not that it failed

[dawsontoth]

Stacked on #1891 (claude/1879-safe-gateway-retry), which is stacked on #1882 (claude/1283-freeform-operations). Stack: #1882 → #1891 → this PR → #1899. It reuses #1891's isReadRequest, so it targets that branch. Retarget it once #1891 merges.

Rebased (2026-10-12). The stack is linear on current stage with no merge commits, and this PR keeps only its own five commits plus two from the review after the rebase. Several PRs this one overlapped landed underneath it (#1871, #1806, #1861, #1867, the staged-release deploy chain), so the conflict resolution changed behaviour in places; Rebase onto stage lists each one.

⊙ Problem

A write that gets a 502, 503 or 504, times out, or never gets a response may already have been applied. Studio still showed it as an ordinary failure. The global mutation toast showed the gateway's body (an nginx HTML page, or central manager's Proxied operation timed out after 30s on instance …) or axios's Request failed with status code 504. Callers then added their own "Failed to restart instance.", "Failed to import …" or "Validation failed! Please make sure the TXT record has been put in place." Someone who believed that and tried again could apply the write a second time: insert the same records, restart again, deploy again. #1891 stopped Studio from replaying writes automatically. The manual retry this copy invited was the remaining way to send one twice.

No status in that set shows the write was not applied. Central manager's operations proxy answers 504 after it has already forwarded the operation (central-manager src/resources/hdbInstance/HDBInstance.js:91-95). Harper answers 503 when the worker it handed an operation to exits or runs out of time (harper server/serverHelpers/registeredOperations.ts:129, :234). Axios reports a connection that dropped after the request went out as ERR_NETWORK, which is the same code it uses for a CORS failure.

❓ Your call: This covers every write surface the review found, which makes it 50 files after the rebase, most of them a one-line guard. The global toast alone would take about five files, but rename and the per-target loops would still say "failed", and callers' own toasts would still contradict the warning. The caller audit could be split into a second PR if this is too much to review at once.

💡 Solution

isUnansweredWrite recognizes these failures from the request and the status, never the body. It takes a real AxiosError that carries its config and has no verdict: a 502, 503 or 504, or no response with ERR_NETWORK, ETIMEDOUT or ECONNABORTED. Then it checks that the request was not a read, using #1891's isReadRequest, so a write is classified by the same rule the gateway retry uses. That check comes last because it may parse a serialized body, and only these failures need it. describeError checks it first and returns our own copy: the title "Outcome unknown", then the message "The server couldn't confirm whether that went through. Check whether it took effect before you try again, or it may happen twice." Every mutation that keeps the global toast now shows that copy, and so does every other describeError caller. The predicate only affects what is displayed. The error itself is not rewritten, because shouldKeepEvent matches timeouts and Network Error on the message text, and callers read error.response.status.

The surfaces that word their own failure had to change too, or they would contradict that toast:

• A caller that adds its own failure toast on top of a mutation's now checks shouldToastOwnFailure first. That covers restart, secrets, orphan-blob cleanup, import, role add/edit/delete, cluster terminate, OAuth settings, and removing a user from the organization.
• A caller with no mutation behind it shows describeError's text itself. Those are rename and the chat tools. The agent now reads the same warning through describeToolError and does not retry an insert as though it had failed.
• A loop that sends one write per target (cluster restart, rolling config, licenses, domain validation) counts these failures separately from refusals, and ends with describeUnansweredWrites instead of "Only N of M restarted".
• These toasts are never collapsed onto a shared id. Each warns about a different write, and a read timing out at the same moment must not replace one through request-timeout.

❓ Your call: A write's 503 counts as unknown here, while the auth forms tell users to retry after a 503 (AGENTS.md, "A 5xx body never reaches an auth form"). This follows #1891's retry rule. Harper's own shed 503s, the request-queue limit (harper server/http.ts:1143-1150) and the write-queue limit (resources/DatabaseTransaction.ts:1323), are refusals, so for those this copy is more cautious than it needs to be. The status alone can't separate them from the worker-exit 503, and the auth forms have already tried and dropped body-based heuristics twice. Excluding 503 is a one-line change to NO_VERDICT_STATUSES.

❓ Your call: When some role removals are refused and others go unanswered, the user still sees "Couldn't remove … Please try again." next to the global warning. I kept that wording. Retrying is safe there, because the modal counts a 404 on an already-removed role as success. The cross-model review wanted an aggregate "unknown" message in that case instead.

⚖️ Alternatives

The planning review (codex) returned Framing-Verdict: better-alternative-exists. I adopted all three corrections. The plan had left the per-target loops, the chat tools and the central-manager caller toasts for a follow-up, and they are all covered here. It had used one shared toast id for every unknown write, which would have let two concurrent warnings overwrite each other, so these toasts now have no id. It had also made package_component a read, which would have let the gateway retry rebuild a large archive three more times, so that request now sets skipGatewayRetry.

• An axios interceptor that rewrites error.message or wraps the error would also reach every error.message and String(error) caller. Rejected: shouldKeepEvent (src/integrations/datadog/shouldKeepEvent.ts:224-275) recognizes timeouts, 401s, 5xx and Network Error by message, so the [Monitoring] AxiosError: API request timeouts (15–60s) affecting multiple views (regression since v2.111.3) #1371 flood would return to Error Tracking. Callers that branch on response.status would also break. And it would cover instance clients only, not central-manager writes.
• Change only errorHandler. Rejected: rename and the per-target loops never reach the global toast, the old secrets.ts wrapping hid the status even from it, and callers' own "Failed to …" toasts would still contradict it.
• Per-caller copy at each write site. Rejected: there are about 40 write operations, and any new one could forget it.
• Idempotency keys would remove the problem itself. Neither Harper's operations API nor central manager's proxy supports them.
• Reconcile after the write, as the domain add form already does (isIndeterminate plus a bounded refetch). This gives a real verdict, but many operations have no state that can be queried afterwards, so it can't replace the general warning. The domain validation loop does refetch now.

🔧 Changes

• src/integrations/api/unansweredWrite.ts (new): the predicate, the copy, the aggregate sentence, and NO_RESPONSE_CODES, now shared with the auth forms.
• src/react-query/queryClient.ts: describeError's unknown-outcome branch, shouldToastOwnFailure, and toasts that are not collapsed.
• src/features/auth/describeAuthFailure.ts: uses the shared code set instead of its own copy. Its behavior is unchanged.
• src/integrations/api/isReadOperation.ts: package_component is a read (harper components/operations.js:393-448 only packs files). Before this change, a download that timed out would have been reported as possibly applied. The restart gate now holds it instead of refusing it, and the operations console no longer asks for confirmation before sending it. packageComponent.ts sets skipGatewayRetry, which retryGatewayErrors.ts now documents.
• src/integrations/api/instance/secrets/secrets.ts: an unanswered AxiosError is rethrown unchanged, checked before fix(datadog): withhold failed secrets-operation text, which quotes secret names #1806's SecretsOperationError wrapping: central manager's proxy answers a 504 with a JSON error body of the same shape as a Harper refusal, so without the check first it would be re-wrapped and lose its status (pinned). Datadog reads only name, message, stack, cause and dd_context from an error, not config (@datadog/browser-core 7.15.0 src/domain/console/consoleObservable.ts:72-119, src/domain/error/error.ts:139-142), and an AxiosError's message is axios's own, so fix(datadog): withhold failed secrets-operation text, which quotes secret names #1806's secret-name withholding is unaffected.
• Mutation callers that check shouldToastOwnFailure: restart, secrets add/edit/delete and grants, orphan-blob cleanup, role add, role edit/delete, cluster terminate, OAuth settings, and organization removal, which now shows no success toast when every failure was unanswered.
• Direct callers that show the shared copy: useRenameFiles and RenameFileModal. Since Show a failed app import or redeploy once, and keep a failed import beside its form #1871 the deploy mutation opts out of the global toast, so every deploy surface shows the copy itself under one title, deployFailureTitle ("Couldn't confirm my-app was imported / staged / redeployed / activated", never "Failed to …"): the import form, the redeploy modal's progress panel and late toast and buffered toast, and the staged-release activation, whose progress panel says so too.
• Per-target loops: cluster restart, rolling config, licenses, and domain validation, which also refetches the list. Their per-step loading toast says "Could Not Confirm …" instead of "Failed …". The cluster-restart, rolling-config and license loops classify each failure where they catch it; after the rebase they are feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861/fix(clusters): Restart Cluster reports a failed cluster load instead of staying disabled #1867's rewritten loops (getClusterRestartTargets, the 5.2+ fan-out), with this PR's counting applied to them. The license warning also counts licenses refused outright beside the unanswered ones, as domain validation does. The cluster-restart and rolling-config warnings get that count from fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899's describeUncertainRollingOutcome, which rewrites both toasts.
• A restart with no verdict stays marked until waitUntilAnsweringAfterRestart sees the target again or gives up, as the operations console already did. The Restart button shows the warning and then holds the mark while it watches. The cluster loop waits on that member before it restarts the next one. Releasing at once let the tracker refetch an instance that was going down, so connectivity errors toasted beside the warning, and let the loop take down the next member while this one might still be down. DESIGN.md records it.
• An unanswered redeploy or import refreshes what the warning tells the user to check. The redeploy modal refetches the components list with live progress and without it. The import refetches the instance and reloads the file tree. Each refreshes once, when the request gives up, so a deploy that is still installing may not show yet. The activation already refetched on every failure.
• Chat write tools now return describeToolError: createApp, deleteTableRecords, dropComponentFile, insertTableRecords, restartHTTPService, setComponentFile, updateTableRecords.
• DESIGN.md: a new note, "A write with no verdict never reads as failed".

❓ Your call: A restart with no verdict holds the target's reads for the length of the watch, about three to four minutes, even when the cause is the user's own network dropping. Holding only on a gateway 5xx, not on a timeout or ERR_NETWORK, is a one-condition change. But a timeout is also how a restart looks when it took the target down mid-reply.

❓ Your call: The cluster loop waits out each unanswered member's watch before it restarts the next, so several unanswered members add up at three to four minutes each, and Cancel takes effect only once the current wait ends. The alternative is to stop at the first unanswered member and leave the rest to the user, which is what #1899 does for a member that accepted the restart and never came back.

🔀 Rebase onto stage

Resolved by hand, against git merge-tree --merge-base <old #1891 head> <new #1891 head> <old #1897 head>. Every auto-merged file matches that reference; the conflicted ones differ where noted:

• Import and redeploy (Show a failed app import or redeploy once, and keep a failed import beside its form #1871 landed). The deploy mutation now opts out of the global toast, so the shouldToastOwnFailure checks this PR had there would have left an unanswered import or redeploy with no warning at all. Instead each shows describeError's copy in its own display (the import form's inline failure, the redeploy panel, its late and buffered toasts) under a title that never says "Failed", and still refreshes what the warning says to check. Show a failed app import or redeploy once, and keep a failed import beside its form #1871's own tests moved into this PR's cases: import, redeploy; the .tsx test files this PR used to add are gone.
• Staged-release activation (new on stage). The same gap on a surface this PR's audit predates: "Failed to activate" with axios's text and no warning. Fixed in its own commit, which also makes deployFailureTitle the one place the deploy title is decided (pinned, panel).
• Secrets (fix(datadog): withhold failed secrets-operation text, which quotes secret names #1806 landed). The unanswered check runs before SecretsOperationError wrapping, as above.
• Cluster restart and rolling config (feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861/fix(clusters): Restart Cluster reports a failed cluster load instead of staying disabled #1867 landed). Those PRs rewrote both loops; this PR's counting, per-step copy and the cluster loop's wait on an unanswered member are applied to the new code, keeping fix(clusters): Restart Cluster reports a failed cluster load instead of staying disabled #1867's failed-load toast and Cancel-during-check. New tests pin them against the real loops: cluster, its wait, rolling.
• Add/add test files. useApplyLicensesClick.test.tsx and useRestartClusterClick.test.tsx now exist on stage; this PR's cases were folded into them on stage's harness (licenses).

❓ Your call: the activation fix (fix(deploy): never call a staged-release activation with no verdict failed) goes beyond resolving conflicts: it extends this PR to a surface that landed underneath it. Dropping that commit restores the import and redeploy modal's own copies of the title rule.

Filed while reviewing: #1895. A restart Harper accepted, on a target that is slow to answer again, still shows "Failed to restart". That request was answered with success, so it is not an unanswered write, and this PR does not change it.

✅ Verification

• Through the real client chain: unansweredWrite.integration.test.tsx builds a real getInstanceClient client whose adapter fails with an AxiosError. It runs the request as a mutation through a QueryClient built on the app's mutationErrorHandler. A 504 on insert, a 502 on deploy_component, a 503 with Harper's worker-exit text on restart, and a timeout on drop_table each raise exactly one "Outcome unknown" toast, never the gateway body. A refused write keeps the server's words, a read keeps its own text after the gateway retry gives up, and a package_component download is sent once on a 504 and is never called possibly applied.

• Each surface: restart shows one warning and no "Failed to restart". rename shows the shared copy. licenses counts an unanswered license separately from a refused one. domain validation mixes a timeout with a 400 and shows both counts. role add skips its own toast only when the request went unanswered. secrets set, delete and grant reject with the AxiosError itself. From the adjudicated round: restart keeps the mark until the target answers again and releases it at once on a refusal. The cluster loop waits on an unanswered member before it restarts the next one, and does not wait on a refused one. Licenses still counts a refused license beside an unanswered one. Import and redeploy, with and without live progress, refresh after an unanswered request and not after a refused one.

• Unit: unansweredWrite.test.ts covers all three statuses, all three no-response codes, object and serialized bodies, central-manager bodies, 4xx/500, local failures (ERR_CANCELED, config errors, ERR_TARGET_RESTARTING), reads, and non-Axios lookalikes. queryClient.test.ts checks the exact copy and confirms that toasts are not collapsed. isReadOperation.test.ts checks that package_component is a read and package_component_project is not.

• Mutation checks, each reverted afterwards. Removing describeError's branch turns 8 tests red, and it puts back exactly the behavior this PR fixes, so it doubles as the fails-on-base check. Each of these turns at least one test red: removing the restart check, restoring the secrets wrapping, removing the rename branch, dropping package_component$, dropping skipGatewayRetry, collapsing the toast id, dropping the read filter (7 red), removing the license counter, removing the role-add check, and removing the domain-validation branch. Reverting each of the adjudicated round's fixes also turns its test red: the restart hold, the cluster wait, the license refusal count and the import refresh 1 each, and the redeploy refresh 2.

• Gates on the head: npx vitest run exit 0 (520 files, 4983 passed, 1 expected fail, 11 skipped; the pre-commit hook also ran the full suite on every commit), npx tsc -b exit 0, npx oxlint --format stylish . exit 0, npx dprint check exit 0, all on Node 24.21.0.

• Mutation checks on the rebase's own guards, each reverted locally and each turned a test red: the secrets unanswered-first check (the 504-with-JSON test), the import title and its refresh, the redeploy title in both paths and both refreshes, the cluster and rolling-config unanswered counting, the cluster loop's wait, the license refused count, the shared deployFailureTitle branch, and the activation's toast and panel copy.

• Not browser-verified. A gateway status can't be produced on demand against a live instance, so the adapter-level test above is how this was verified end to end.

• Cross-model review: four rounds. Rounds 1 and 2 ran codex (graded) and gemini only, because the Harper domain leg failed auth (an expired OAuth session) both times, so nothing was adjudicated then. Round 1 found the domain-validation loop, which is fixed, and the slow-recovery restart, which is A restart Harper accepted reads as failed when the target is slow to answer again #1895. I rejected these findings on evidence:

  • Gemini said useRestartInstanceClick has no mutation behind it. It does: useRestartInstance is a useMutation, and the restart test runs through the global handler and sees the warning.
  • Gemini said EditUserModal can leave the modal stuck. setIsRemoving(false) and onUserUpdated() run after every branch.
  • Gemini (round 2) cited a "Could not create the new file" catch in RenameFileModal. That catch does not exist. The modal's only catch is the one this PR changed.

  Rounds 3 (full, at a35e2bed) and 4 (delta, at a72b4b9a) ran codex, gemini and the Harper domain adjudicator. Both were independent=true, round 4 reported convergence=converged, and the adjudicated severity is minor. Accepted and fixed: an unanswered restart released its mark at once, the license warning dropped refused licenses, an unanswered redeploy or import refreshed nothing, the new DESIGN.md note overstated how long the mark holds, and one JSDoc only restated its code. Kept open, not fixed here:

  • A restart Harper accepted but never confirmed back still reads "Failed to restart", and a cluster loop moves on past a member whose watch gave up, whether that member was unanswered or accepted. Both are pre-existing. fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899, stacked on this PR for A restart Harper accepted reads as failed when the target is slow to answer again #1895, stops the loop for an accepted restart.
  • The cluster-restart and rolling-config warnings leave out refused members when others went unanswered. fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899 rewrites those toasts with the count.
  • The secrets key-rotation retry runs before the unanswered check. The adjudicator found it can't fire on a gateway page: it needs Harper's own JSON refusal text, which is a verdict (secrets.ts:60-61). Pre-existing, and codex's and gemini's "major" was downgraded to a nit.
  • The redeploy refresh is one snapshot taken when the request gives up, and live progress still draws the warning in red.
  • The role-removal wording, the ❓ above. The adjudicator agreed a retry is safe there and rated it a nit.
  • shouldToastOwnFailure's JSDoc opens by restating its use. fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899 rewrites that comment.

  Rejected on evidence: Gemini said a user removal whose every role removal goes unanswered shows nothing. Each removal is a useMutation without skipGlobalErrorToast, so the global handler toasts it. The Cursor legs were not selected in rounds 3 and 4. In rounds 1 and 2 they failed no-receipt (the 1Password SSH agent refused git fetch).

• Rebase review round (full, at 03165c9c, after the rebase and the activation fix): codex (graded), gemini and the Harper domain adjudicator ran, independent=true, adjudicated severity minor. Both Cursor legs failed no-receipt (the 1Password SSH agent refused their git fetch).

  • Taken: DeployVerb no longer exported (no consumer outside its module), and two comments that repeated their neighbours dropped.
  • Declined, codex major → adjudicated minor: the cluster loop carries on after an unanswered member's watch gives up. That is this PR's documented give-up (the ❓ above); fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899, stacked on this one, now stops there, which is where the stop rule and its copy live.
  • Declined, codex major → adjudicated nit, pre-existing: the rolling config update does not wait on an unanswered restart_service. Harper replaces HTTP workers an eighth at a time with the replacements started first (harper server/threads/manageThreads.js:1403-1419), so the member keeps answering, and the diff does not change that control flow. fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899 now waits and stops there too, for a restart that may have run onto a configuration that broke the member.
  • Declined, gemini major (rejected again, as in round 2): a user removal whose role removals all go unanswered is not silent. useRemoveUserFromOrganizationRole is a useMutation without skipGlobalErrorToast, so each failure reaches the global handler's "Outcome unknown" toast.
  • Declined, gemini nit: most of the comments it listed state why, not what; the adjudicator agreed.

• Delta round (at the head, after the nit commit): codex, gemini and the adjudicator re-ran; the two nits are resolved, nothing new in the delta. Left as filed: the relayed-500 ❓ below, the two loop cases fix(restart): say a restart Harper accepted is not back yet, never that it failed #1899 handles, two why-comments the adjudicator would still trim (useImportApplication.ts's refresh note, queryClient.ts's never-collapsed note), and a pre-existing nit: a directory rename whose final drop_component gets no verdict does not reload the tree the warning tells the user to check (RenameFileModal.tsx; this PR changed only its toast). Gemini's "EditUserModal stays open" was dropped again: setIsRemoving(false) and onUserUpdated() run on every path.

❓ Your call: the adjudicator's one surviving minor: a write cut off after the request went out can come back through central manager as a 500 carrying socket hang up / ECONNRESET / EPIPE (the restart gate already reads those, src/lib/restart/restartGate.ts:83-84). This PR's rule decides by status and never by body, so that case still reads "Failed", and the cluster loop treats it as a refusal. Counting those relayed post-connect errors as no-verdict would mean reading the body for one known shape; I left the rule status-only, as the PR decided.

Closes #1890

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

Related PRs: #1891 overlaps (stack base, this PR uses its isReadRequest), #1882 overlaps (stack base, below #1891), #1899 overlaps (stacked on this PR: restarts Harper accepted but never confirmed back, the loop counts, and the stop at a no-verdict member that never came back), #1871 overlaps (merged; opted the deploy mutation out of the global toast, so import and redeploy now show the warning themselves), #1806 overlaps (merged; secrets error wrapping), #1861 overlaps (merged; rolling config loop), #1867 overlaps (merged; restart and license loops), #1876 overlaps (merged; the staged-release activation this PR now covers), #1898 overlaps (merged; when the deploy fallback may resend)
Complexity: medium

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

_{Review-Attention: study ~15m (sensitive: describeAuthFailure.ts, SecretGrantsEditor.tsx +2; decisions: status-only-verdict, one-predicate-both-clients, package-component-as-read, advance-after-watch-gives-up, per-caller-toast-guard, do-less-alternative) @ 7b6f747}

[gemini-code-assist]

Code Review

This pull request introduces a robust error-handling mechanism for 'unanswered writes'—write operations that fail with gateway errors (502, 503, 504) or network timeouts, leaving their execution status unknown. It adds a new utility module unansweredWrite.ts and updates various UI components, hooks, and mutations to prevent misleading 'failed' messages, instead prompting users to verify the outcome before retrying. Additionally, the PR updates DESIGN.md to document this behavior, adjusts gateway retry configurations for costly read operations like package_component, and includes comprehensive unit and integration tests. I have no feedback to provide as there are no review comments.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	77.38%	13289 / 17173
🔵	Statements	77.33%	14108 / 18242
🔵	Functions	72.24%	3499 / 4843
🔵	Branches	72.26%	10426 / 14428

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/features/auth/describeAuthFailure.ts	100%	100%	100%	100%
src/features/cluster/domains/Management.tsx	91.08%	87.69%	90%	92.78%	100, 127, 264-275, 283, 289-290
src/features/clusters/components/ClusterCard.tsx	54.02%	82.97%	25.92%	54.76%	107-119, 123-124, 127, 130-163, 267-296, 382, 457-496
src/features/instance/applications/components/Chat/tools/describeToolError.ts	100%	50%	100%	100%
src/features/instance/applications/components/Chat/tools/createApp/execute.ts	75%	50%	50%	75%	21-23, 75-91
src/features/instance/applications/components/Chat/tools/deleteTableRecords/execute.ts	0%	100%	0%	0%	12-29
src/features/instance/applications/components/Chat/tools/dropComponentFile/execute.ts	0%	100%	0%	0%	11-24
src/features/instance/applications/components/Chat/tools/insertTableRecords/execute.ts	0%	100%	0%	0%	12-29
src/features/instance/applications/components/Chat/tools/restartHTTPService/execute.ts	77.77%	100%	100%	77.77%	42-52
src/features/instance/applications/components/Chat/tools/setComponentFile/execute.ts	0%	100%	0%	0%	13-32
src/features/instance/applications/components/Chat/tools/updateTableRecords/execute.ts	0%	100%	0%	0%	12-29
src/features/instance/applications/components/NewApplication/useImportApplication.ts	91.78%	82.6%	100%	91.54%	112-116, 118-122, 137-140, 174-175
src/features/instance/applications/hooks/useRenameFiles.tsx	56.66%	35%	40%	55.93%	27, 36, 76, 88, 97-100, 111, 117-169
src/features/instance/applications/modals/RedeployApplicationModal.tsx	75.22%	51.94%	91.66%	74.77%	103, 126-141, 162-169, 173, 179, 197, 211-213, 225-234, 246, 334-344
src/features/instance/applications/modals/RenameFileModal.tsx	37.03%	14.28%	50%	36.53%	40, 47-48, 82-143, 148-149
src/features/instance/applications/modals/reportDeployHealth.ts	84.61%	73.58%	100%	84%	63-67, 72-91
src/features/instance/config/deployments/components/ActivateStagedRelease.tsx	100%	81.25%	100%	100%
src/features/instance/config/secrets/SecretGrantsEditor.tsx	0%	0%	0%	0%	30-78
src/features/instance/databases/components/DatabaseTableView.tsx	72.33%	73.84%	64.91%	71.95%	269, 402-405, 450-459, 636-650, 695-711, 715-723, 732-740, 746-774, 785, 809, 835-850, 857-861, 864-891, 907, 911, 941-942, 1083-1093
src/features/instance/operations/index.tsx	98.71%	88.15%	100%	98.7%	96
src/features/instance/secrets/SecretModals.tsx	88.88%	85.96%	92.3%	88.88%	130-132, 287-288, 308-309
src/features/organization/roles/modals/AddOrganizationRoleModal.tsx	65.62%	69.23%	50%	65.62%	73, 82, 92-98, 152, 170-198
src/features/organization/roles/modals/EditOrganizationRoleModal.tsx	45.61%	56.86%	33.33%	46.42%	43, 63-67, 102-118, 144, 151-187, 280-310
src/features/organization/settings/index.tsx	72.6%	66.66%	64.7%	74.64%	85-86, 126, 127, 139-143, 150-151, 156-157, 162-165, 204, 268-374, 409-410, 484-485
src/features/organization/users/modals/EditUserModal.tsx	0%	0%	0%	0%	36-172
src/hooks/useApplyLicensesClick.tsx	93.02%	84.84%	50%	92.85%	122, 133, 154
src/hooks/useRestartClusterClick.tsx	93.15%	96.15%	63.63%	92.85%	38, 84, 206, 217, 240
src/hooks/useRestartInstanceClick.ts	89.65%	73.07%	50%	89.65%	43, 84, 98
src/hooks/useRollingConfigUpdate.tsx	95.65%	98.61%	71.42%	95.5%	118, 260, 271, 295
src/integrations/api/isReadOperation.ts	100%	100%	100%	100%
src/integrations/api/unansweredWrite.ts	100%	91.66%	100%	100%
src/integrations/api/instance/applications/packageComponent.ts	66.66%	100%	100%	66.66%	34
src/integrations/api/instance/secrets/secrets.ts	91.3%	89.47%	85%	90.9%	139-146
src/integrations/api/instance/status/restartInstance.ts	100%	100%	100%	100%
src/integrations/api/instance/status/restartUnconfirmed.ts	100%	96.29%	100%	100%
src/react-query/queryClient.ts	98.18%	100%	85.71%	98.18%	121

Generated in workflow #2322 for commit 6cd6fbc by the Vitest Coverage Report Action