Pet fee atomic write

Decision: a pet fee's company amount and each property's own value save together in one server call, all or nothing.

2026-10-13 · fee card follow-up to #19140 · decided by the coordinator for Gera · property names are not used

Decision: option (a). One server call writes a pet fee's company amount and every property value it touches in a single DynamoDB transaction. Above what one transaction can hold, "Apply to all" is refused with a plain message pointing to Specific properties. There is no silent fallback to several smaller writes.

The problem

On the fee card, pet deposit and pet rent use one company amount that properties without their own value inherit. "Apply to all" therefore makes two kinds of write: the company amount, then clearing each property's own value that differs. Undo does the same in reverse. Today the browser sends these as separate calls in order. Review rounds 1 and 3 on #19140 each found a case where one call landing and the next failing left a property charging no pet fee. Both were patched, but it is the same root cause: a money change split across calls the browser has to sequence.

Options

(a) Refuse above the limit — chosen

One transaction holds every write. If a company has more properties than one transaction can carry, "Apply to all" on a pet fee is disabled and refused with: "This company has too many properties to change in one go. Use Specific properties to set them in groups." Simple, honest, and well above every company today.

(b) Fall back to ordered calls for big companies

Use today's guarded order (properties first, company amount last) when the change does not fit. Safe in the common failure, but not all or nothing, and it keeps two ways to make the same change.

(c) Pending marker, finished in the background

Record the intended change, then apply it in steps a worker can retry. Handles any size, but adds a new moving part and a window where the card shows a change that is not fully applied.

Why (a)

It removes the defect class instead of patching each ordering: nothing is ever half saved.
The limit sits far above real companies (the largest has about 52 properties).
Option (b) would keep the very sequencing this replaces, and (c) adds infrastructure for a size no company has.

The limit, worked out

Company amount change	Writes it takes	Room left for properties
First company amount (create)	3 (the row, its change log entry, the version bump)	97
Replace a company amount (supersede)	5 (ends the old row, writes its history, the new row, log, bump)	95
Clear the company amount (Undo of a first amount)	4	96
Properties only (no company change)	0	100

DynamoDB allows 100 writes and 4 MB per transaction. Each property's change is a targeted update of that one fee and its confirmation stamp, not a full record, so the size limit is not reached first. The writer refuses before building anything when the count is over.

What goes through the new writer

Yes: every pet "Set for all" button (Apply, Apply to N remaining, Apply to all) and their Undo. The company-only ones simply carry no property writes, so the card has one pet "Set for all" path.
No, unchanged: Specific properties and Set individually on a pet fee (property values only, one door per property as today), and the three non-pet fees (property values only, no company amount).

Each property's write is conditioned on the value the card last read, so a teammate's change in between cancels the whole transaction instead of being overwritten. Clara's phone-agent caches refresh after a successful save only.

Storage

The company amount has always been written straight to DynamoDB (every settings route imports putSettingAttachment from src/lib/data/dynamo/; there is no JSON-file version of a setting). The new writer is DynamoDB-only for the same reason: there is no second implementation to keep in step.

Plan, two pull requests

The writer. Split putSettingAttachment / endSettingAttachment into "prepare the writes" and "commit" (pure extraction, same behaviour and tests), and add the all-or-nothing pet writer with its limit check. Tests prove a failed property condition writes nothing at all.
The route and the card. A settings route that checks permissions like both current doors and calls the writer; the card's pet Set-for-all and Undo each become one call, and "Apply to all" is disabled with the message above when the company is over the limit (and refused by the server regardless).