Tracing a Pipeline End-to-End

Every CLI command has a registration function. Start there.

ix search registerIngestCommand --kind function

registerIngestCommand (function)
  ix-cli/src/cli/commands/ingest.ts:153-183
  tier: 0  matchSource: name_exact

callees shows what a function calls. Chain it to go deeper.

ix callees registerIngestCommand
# → ingestFiles, ingestGitHub

ix callees ingestFiles
# → loadExistingHashes, loadIngestionModules, flushBatch,
#   sha256, commitPreparedPatches, IxClient.commitPatchBatch, ...

Two branches from the entry: local ingestion and GitHub. Following the local path reveals the full pipeline: discover → parse → resolve edges → flush in batches.

When you need implementation details, read the specific function.

ix read flushBatch

ix-cli/src/cli/commands/ingest.ts:340-383

 340 | const flushBatch = async (batch) => {
 341 |   if (batch.length === 0) return;
 342 |   const resolvedEdges = resolveEdgesFn!(batch.map(f => f.parsed));
 ...
 366 |   await commitPreparedPatches(client, patches);
 ...

Batches are prepared and sent via commitPreparedPatches, which handles the CLI → server boundary.

The same name often exists on both sides. Use --pick to disambiguate.

ix search commitPatch --kind function
# 1. commitPatch (method) — ix-cli/src/client/api.ts        ← CLI side
# 2. commitPatch (function) — ArangoGraphWriteApi.scala      ← server side

ix callees commitPatch --pick 2
# → beginTransaction, checkIdempotency, doCommit, commitTransaction

Keep following callees to reach the bottom of the stack.

ix callees doCommit
# → loadLatestRev, loadActiveClaimsCache, executeOp,
#   retireAbsentClaimsBatch, storePatch, storeIdempotencyKey,
#   updateRevision, commitTransaction

executeOp is where AQL mutations actually hit ArangoDB. It handles 7 operation types: UpsertNode, UpsertEdge, DeleteNode, DeleteEdge, AssertClaim, RetractClaim. Nodes are tombstoned (soft-deleted with deleted_rev), not physically removed.

Instead of tracing hop-by-hop, depends --depth 3 gives you the full tree at once.

ix depends commitPatch --pick 2 --depth 3

commitPatch (ArangoGraphWriteApi.scala)
  └─ beginTransaction
  └─ checkIdempotency
  └─ doCommit
      └─ loadLatestRev
      └─ executeOp
          └─ client.execute (ArangoClient)
      └─ retireAbsentClaimsBatch
      └─ storePatch
      └─ updateRevision
  └─ commitTransaction

registerIngestCommand           CLI entry point
  → ingestFiles                  filesystem walk + parse loop
    → loadIngestionModules       dynamic Tree-Sitter loading
    → flushBatch                 batch with fallback
      → commitPreparedPatches    prepare and send batch
        → IxClient.commitPatchBatch  HTTP POST (batch)
        → IxClient.commitPatch       HTTP POST (per-file fallback)
          ─── HTTP boundary ───
          → commitPatch           Scala REST handler
            → beginTransaction
            → checkIdempotency
            → doCommit
              → loadLatestRev
              → executeOp          7 AQL mutation cases
              → retireAbsentClaimsBatch
              → storePatch
              → updateRevision
            → commitTransaction

9 hops from CLI to database. Every hop discovered using callees, read, and search — no file browsing needed.