Expand description
Torna client SDK – the PathPlanner.
Integrators call insert/update/delete/find with a 32-byte key; the planner reads
the tree off-chain (via an AccountReader) and produces a ready Instruction
with the exact account set. node_idx, bumps, paths, and spares never leak out.
Layout constants mirror the FROZEN ABI (torna_docs/abi.md). If the engine layout changes, change it here too – the cpitest/inttest in torna/integration will catch a mismatch because the SDK-built instructions run against the real torna.so.
Modules§
- keys
- Orderbook key convention (CLOB-specific; the core Tree is key-agnostic).
Structs§
- Header
- Parsed, cache-relevant header fields.
- Tree
- A handle to one tree: (program, creator, tree_id). All PDA/seed logic lives here.
Enums§
Constants§
- ALLOC_
SIZE - ERR_
BAD_ PATH - ERR_
DUPLICATE_ KEY - ERR_
KEY_ NOT_ FOUND - ERR_
NEED_ SPLIT_ SLOT - IX_
DELETE - IX_
DELETE_ FAST - IX_FIND
- IX_
INIT_ TREE - IX_
INSERT - IX_
INSERT_ FAST - IX_
UPDATE_ FAST - KEY_
SIZE - NODE_
HDR - TREE_
HEADER_ SIZE
Traits§
- Account
Reader - Anything that can fetch raw account data (LiteSVM, RPC, a cache).
Functions§
- retry
- Re-resolve + resubmit up to
attemptstimes.fshould resolve the instruction from FRESH state (the planner reads live accounts each call) and submit it, returningAttempt::Staleto retry. This is the SDK’s staleness model: splits are rare (leaf-full), but between resolving a path and the tx landing a concurrent writer may have split/merged a node, invalidating node_idx -> ERR_BAD_PATH; the client just re-resolves. Compare Header::structure_epoch to detect it cheaply.