Twee mensen op hetzelfde account raken elkaars werk nooit kwijt.
Elke wijziging in Growth-OS gaat via de server, in één transactie, precies één keer. Bewerk jij hetzelfde account als een collega, dan krijgt de tweede opslag te horen dat het record verder is in plaats van er stilletjes overheen te schrijven. Valt je verbinding weg en probeert de app het opnieuw, dan krijg je het oorspronkelijke antwoord terug, geen tweede besluit.
1
place that writes to our database
1
transaction for the record, its jobs and its receipt
3
kinds of retry key supported
Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw, en anders.
Two people open the same account note, both save, and the later save wins the whole document. The reasoning someone typed out is simply gone, and nobody can say when. A version check turns that into a refusal you can see and resolve.
A weak connection on the train, a second tap on save, and now there are two expenses or two meeting records for the same thing. Merging them later is guesswork. A mutation receipt makes the second attempt return the first result.
A transcript extraction gets queued, then the save it belonged to fails. The job runs against a record that never existed. Queueing inside the same transaction means the job only exists if the change did.
Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.
Bad input stops at the contract
Every write is parsed against a shared schema before it reaches the data. The same parse runs on the first attempt and on every retry.
Duplicates queue instead of racing
A database lock makes two identical requests take turns rather than collide. The server then checks whether this save already has a receipt.
Everything commits together
The record, its revision snapshot, any background work it triggers, and its receipt all land in one PostgreSQL transaction. All of it, or none of it.
Retries replay the receipt
A repeat request finds the receipt and gets the original answer and transaction ID back. Reusing the same ID for a different write is rejected rather than accepted.
Interactief voorbeeld
Deze rondleiding toont het geïmplementeerde backendcontract zonder account, credentials of providercalls.
Interactief voorbeeld
Stap 1 van 4: Parse input
Alleen deterministische voorbeelddata. De interactie gebruikt geen account-, provider- of netwerkverbinding.
Kernpunten
Nothing in the browser writes to our database. Each save crosses a shared contract, takes its identity from the session, and commits on the server.
Every save carries a mutation ID and leaves a receipt. Send it again and the server replays that receipt instead of creating a second row.
Records carry a version. A save built on an older version fails with a message saying it changed since it was loaded, so nobody silently loses a paragraph.
Technische garanties
Dit beschermt de schrijfactie zelf: identiteit, projectbereik, dubbele verzoeken en volgorde. Of een besluit een goed besluit is, blijft aan ons om te beoordelen, en regels die bij één soort record horen, staan in het commando van dat onderdeel.
De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:
src/server/transactions.tssrc/server/permissions.tsdocs/CONVENTIONS.mdDeze functies delen contracten en grenzen met deze pagina.
De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.