Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?
SaaS
What are the exact steps to reproduce this issue?
Hello Baserow team,
We are building an inventory workflow on Baserow Cloud and need to confirm a supported server-side consistency contract before enabling stock operations. This is a capability question, not a claim that Baserow has no transactions.
Minimal operation: check the current version/ownership of one stock unit, update that unit and its document line in another table, and persist a command result. Two concurrent requests must not both apply an incompatible effect; retrying after a lost HTTP response must return the original result without repeating the effect.
We reviewed the public OpenAPI and the official 2.3.4 source. The source uses transaction.atomic and row locks for REST batch updates, while successive automation nodes run as separate tasks. We have not verified that the current Cloud build is identical. Same-table batch atomicity alone does not establish conditional updates or a shared commit across the unit, document line and result journal.
Could you clarify:
- Does current Cloud offer a documented endpoint or supported extension for a conditional, atomic update across these related tables? Please link the contract and specify version/ownership preconditions (for example expected_version, If-Match or fencing token).
- Are the precondition check and all writes in the same transaction, and what happens when two requests conflict?
- Is an idempotency key supported with a durable saved response after a timeout, including rejection of the same key with a different payload?
- Can permissions enforce this write path against direct table edits, other API tokens, automations and undo in an agreed role model?
- What are the guarantees if a failure occurs between the stock update, result journal write and HTTP response?
- Which Cloud plans support this, and how can it be tested safely on isolated test data? If it requires a self-hosted plugin or external authoritative ledger, please distinguish that from current Cloud functionality.
A GET followed by PATCH, or creating a unique claim before an unconditional PATCH, would not on its own provide the commit-time guarantees we need. We only need atomicity for one stock unit plus its related line and command result, not necessarily an entire multi-line document.
No private database records or credentials are included. Thank you for pointing us to the supported approach.