[cristim]

What

Fixes the Settings save reverting backend coverage propagation (#500), and an empty global coverage field saving as 0.

Why

saveGlobalSettings PUT each service row with the coverage cached at load time (or the SP card's DOM value). updateServiceConfig overlays that coverage unconditionally, so it overwrote the value the backend had just copied from a changed default_coverage. Number('') is 0, so a cleared field passed validation.

How

• frontend/src/settings.ts: decide "global coverage changed" and "SP card edited" from the existing savedSnapshot dirty tracking instead of a separate loaded-default variable. When the global default changed, send the new default for every service row; an SP card value overrides it only when the user edited it on the card. Once the global PUT succeeds, the snapshot entry and the cached rows are refreshed (the backend has propagated the default), and each SP card's snapshot entry is refreshed as its row PUT succeeds, so a retry after a partial failure keeps saved SP edits and does not resend stale values. Reject an empty global coverage field with the existing error toast.
• Behaviour change: a changed global coverage now overwrites every service row that the user did not edit on the SP card, matching the backend propagateChangedDefaults, which overwrites coverage on all service_configs rows.
• Tests in frontend/src/__tests__/settings.test.ts: global 50 -> 0 propagates to ec2 and SP compute; an SP card edit in the same save wins; second save does not revert; a saved SP edit survives a further save and does not shield the card from a later global change; partial failure then retry keeps the SP card at its saved value; a further global change after a partial failure reaches the SP card; empty field is rejected. The tests mock all PUTs to succeed except the partial-failure tests.

Verified

The new tests fail on the pre-fix source, and each snapshot/cache refresh removed in turn fails at least one test. Full frontend jest: 92 suites, 3048 passed, 1 skipped. tsc clean, eslint 0 errors.

Not in this PR

The same Number('') pattern in frontend/src/plans.ts:1345 (plan coverage field) and wireInlineRangeValidation showing no inline error for an empty value. #522 stays open for those.

Refs #522

[cristim]

@coderabbitai full review

[coderabbitai]

⚠️ Action not completed

Review rate limited.

---

Your included review limit is currently reached under our Fair Usage Limits Policy. Your current included review allowance is based on your included PR review attempts over the past 7 days. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 4 minutes.

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 2 billable files and costs up to $0.50.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 2 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available. Your 54 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: LeanerCloud/cloud-commitments-platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Essentials
• Run ID: ad2b7165-dba2-4ca1-8632-726d7b2e5759

📥 Commits

Reviewing files that changed from the base of the PR and between d2cdc60 and 70b0dcc.

📒 Files selected for processing (2)

• frontend/src/__tests__/settings.test.ts
• frontend/src/settings.ts

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}