[P1] Add Transactional Batch support

[sajeetharan]

Feature Request

Priority: P1 (High)

Description

Cosmos DB supports transactional batch operations (multiple operations within the same partition key that either all succeed or all fail), but CosmosDB Shell does not expose this capability.

Comparable Features in Other Shells

• mongosh: Session.startTransaction() / commitTransaction()

Proposed Behavior

Add transactional batch support:

• batch begin — Start a batch context for a specific partition key
• batch add <operation> — Add create/replace/upsert/patch/delete operations
• batch execute — Execute all operations atomically
• batch cancel — Discard pending operations
• Show per-operation results and total RU cost

Example Usage

cd /MyDatabase/MyContainer
batch begin --partition-key "pk1"
batch add create '{"id": "1", "pk": "pk1", "name": "Item 1"}'
batch add create '{"id": "2", "pk": "pk1", "name": "Item 2"}'
batch add delete "3"
batch execute

[mkrueger]

Doesn't make much sense - you can write scripts and you've ';' for executing multiple commands.

This is more or less a poor mans script file solution. What should this improve over scripts or ';' command separators?

[sevoku]

I think this is referring to real backend batch operations, see i.e. https://learn.microsoft.com/en-us/azure/cosmos-db/transactional-batch?tabs=dotnet. So the operations are performed as one and either succeed or fail together. The shell won't execute each operation as it occurs in the script, but batch them in one single operation on batch execute. This makes total sense to me, but would require a significant amount of work to implement.

[mkrueger]

If it's a db feature it makes sense. Just not on shell level.

Need to look at what is possible inside the batch.

[tnaum-ms]

Genuine PM question worth sitting with: how often does someone actually reach for transactional batch operations interactively, at a shell prompt? :)

Transactional batches are typically something you design in code, test in code, and run in code. The shell is most valuable for exploration, inspection, and quick one-off operations. The moment you need to carefully compose a set of atomic operations with a specific partition key and reason about rollback, you are probably already writing a script or reaching for an SDK.

That is not an argument against building it, but it does raise a question about whether P1 is the right call. For agentic and MCP-driven workflows there might be a case, but for interactive use the demand feels closer to P2 or P3. Curious what drove the P1 label here.

[sevoku]

I could imagine test case scenarios automated with the shell where it would make sense to have that. But I agree with @tnaum-ms wrt priority.