Transactions

What Exists Today

Vaylix supports:

• MULTI
• EXEC
• DISCARD

The current semantics are intentionally limited to the single-node engine.

Current Guarantees

Inside one session:

1. MULTI starts queueing commands.
2. EXEC evaluates the queued commands against one working state.
3. If every queued command succeeds, one WAL-backed atomic batch commits.
4. If any queued command fails, the batch does not commit.

This gives atomic single-node commit behavior for queued data commands.

EXEC Result Shape

From 0.3.0 onward, successful EXEC responses are returned as typed transport results rather than a rendered string list.

That matters for programmatic clients and SDKs:

• booleans remain booleans
• counts remain counts
• integers remain integers
• value payloads remain distinguishable from NOT_FOUND and other rendered sentinel text

This is a transaction-wire breaking change for 0.2.x clients that decoded EXEC as a simple string array.

Current Limits

• transactions are serialized through the engine worker
• transactions are not MVCC
• transactions are not distributed
• sequence-tagged or pipelined requests are rejected while a transaction is active
• transactions expire after the configured --transaction-max-seconds window
• maintenance mode rejects transaction entry and commit

Commands That Do Not Belong in Transactions

The implementation keeps operational and local-only commands out of EXEC batches, including:

• AUTH
• INFO
• METRICS
• METRICS PROM
• SAVE
• SNAPSHOT
• logical backup and restore flows
• maintenance-mode commands
• local HELP, EXIT, and QUIT

Those are rejected rather than being treated as partially supported behavior.