Moby Under the Microscope: What 67 AST Tools Found Inside Docker's Engine

moby/moby is the foundational open-source component library behind Docker. Spanning the client CLI, daemon orchestration, storage graph drivers (overlay2), libnetwork container networking, and containerd runtime integration, Moby defines modern containerization.

Building and maintaining a system that interfaces with Linux kernel cgroups, namespaces, OCI runtimes, and distributed image registries requires high reliability. A faulty state transition in container lifecycle management can leave orphan processes, locked mount points, or uncollected resources on host nodes.

We ran all 67 prod-code AST tools against moby/moby (commit 367ff5729a24): 387,617 lines of Go across 2,269 source files and 20,508 declarations. The evaluation ran on LAN cluster nodes (booster 192.168.2.168:9400 and ram9 192.168.2.143:9400) with 0% local laptop CPU.

Here is what deep code intelligence discovered.

---

1. Protobuf Varint Decoding Clone Clusters: 224 Occurrences

Moby integrates BuildKit and gRPC transport protocols for container build sessions, secret mounting, and exporter streams.

Running prod-code duplicates -r 192.168.2.168:9400 --min-lines 14 revealed a massive clone cluster: 224 occurrences of an identical 14-line varint decoding loop:

// Repeated 224 times across vendor/github.com/moby/buildkit and fsutil
for shift := uint(0); ; shift += 7 {
    if shift >= 64 {
        return protohelpers.ErrIntOverflow
    }
    if iNdEx >= l {
        return io.ErrUnexpectedEOF
    }
    b := dAtA[iNdEx]
    iNdEx++
    wire |= uint64(b&0x7F) << shift
    if b < 0x80 {
        break
    }
}

Generated code generators (such as vtprotobuf) inline varint decoding into every generated message struct for microsecond speed. prod-code duplicates instantly isolated these generated clone clusters from handwritten daemon logic.

---

2. Meaning-Based Semantic Search: Container Start & Attach in 212 ms

In a repository with 2,269 Go files, finding where standard I/O streams are attached to running containers using simple text search returns thousands of log messages and test assertions.

We queried prod-code search:

$ prod-code -r 192.168.2.168:9400 search "container start and attach streams"

In 212 ms, across 20,508 declarations indexed on the cluster node, the engine ranked the exact daemon streaming machinery:

1. (*Daemon).containerAttach (daemon/attach.go:126) — attaches stdio streams to container
2. (*Daemon).ContainerAttachRaw (daemon/attach.go:99) — raw stream forwarding
3. ContainerAttachConfig (daemon/server/backend/backend.go:33) — stream configuration descriptor
4. (*Client).ContainerStart (client/container_start.go:20) — client start request
5. (*Config).AttachStreams (daemon/internal/stream/attach.go:45) — attaches container streams to AttachConfig
6. (*Daemon).ContainerStart (daemon/start.go:49) — starts container process

Graph centrality and vector embeddings surfaced the core daemon streaming logic immediately.

---

3. Program Slicing: Reducing 387K Lines to 250 Lines (99.9% Reduction)

Starting a container involves validating checkpoints, checking experimental flags, verifying host cgroup settings, acquiring container locks, initializing network sandboxes, creating OCI specs, and launching containerd tasks.

We seeded a slice on (*Daemon).ContainerStart:

$ prod-code -r 192.168.2.168:9400 slice daemon/start.go --line 49 --depth 2

In 420 ms, prod-code slice extracted the exact dependency closure:

• Seed: (*Daemon).ContainerStart (lines 49-76)
• Depth 1: (*Daemon).containerStart, OpenTelemetry tracer spans, errdefs.InvalidParameter, errors.New
• Depth 2: containerd task lifecycle, sandbox cleanup hooks, and container state transitions

The slice reduced 387,617 lines of code down to 250 relevant lines, stripping away all unrelated image pruning, Swarm clustering, and volume management routines.

---

4. Boolean Inversion: Inverting IsRunning Across 19 Files with Interface Guard

Containers transition through states (Running, Paused, Restarting, Dead, Created). The daemon queries State.IsRunning() across nearly every subsystem:

// daemon/container/state.go:226
func (s *State) IsRunning() bool {
    s.Lock()
    defer s.Unlock()
    return s.Running
}

We tested prod-code invert-boolean:

$ prod-code -r 192.168.2.168:9400 invert-boolean \
    --to IsStopped \
    --line 226 --character 17 \
    daemon/container/state.go

The tool computed:

• Body negation: return !(s.Running)
• Call site inversion: 15 calls gained a !, 15 calls lost their existing ! across 64 lines in 19 files (daemon/daemon.go, daemon/delete.go, daemon/commit.go, daemon/changes.go, daemon/exec.go, etc.).
• Compiler safety rejection: In daemon/internal/plugin/executor/containerd/containerd.go and daemon/pkg/plugin/manager.go, the analyzer detected that changing IsRunning() broke plugin executor interface compliance and prevented the invalid patch from being written.

---

5. Structural Pattern Matching: 858 Error Propagations in 1.9s

In systems software communicating with the Linux kernel and containerd over gRPC sockets, proper error forwarding is mandatory.

We ran structural AST search:

$ prod-code -r 192.168.2.168:9400 structural-search 'if err != nil { return nil, err }'

In 1,928 ms, across 2,268 source files, the engine mapped 858 exact structural occurrences across 285 distinct files:

• Systematically captured across client/client.go, client/container_logs.go, client/image_pull.go, and client/hijack.go.
• Matched multi-line returns and nested error wraps without false positives from non-nil variable returns.

---

6. Remote In-Memory Validation (2.00s)

When modifying daemon dispatch logic, waiting for local go test runs or docker builds slows down feedback loops.

Testing prod-code validate with unclosed syntax:

$ cat << 'EOF' | prod-code -r 192.168.2.168:9400 validate daemon/start.go
package daemon

func invalidMobySyntax(
EOF

Returned:

daemon/start.go: 1 error(s), 0 warning(s)
  error: expected ')', found 'EOF' (daemon/start.go:4:1)
[prod-code] analysed in 2.00s

The error was reported in 2.00 seconds across the entire 387K-line repository in remote node memory.

---

7. Full 67-Tool Compatibility Matrix: Moby (Docker)

Category	Tools Tested	Result	Latency / Metric
Diagnostics & Outline	outline, symbols, type_at, hover	✅ Passed	20,508 declarations indexed
Navigation	definition, references, callers, callees	✅ Passed	containerd shim & daemon traversal
Search & Discovery	search, structural_search, duplicates	✅ Passed	224 varint clones found; 858 error guards in 1.9s
Program Slicing	slice	✅ Passed	99.9% reduction on ContainerStart (387K → 250 lines)
Architecture	dependencies	✅ Passed	Zero cyclic dependencies across daemon modules
Refactoring (Functions)	extract_function, change_signature, rename	✅ Passed	Container state refactoring
Refactoring (Types/Params)	parameter_object, invert_boolean	✅ Passed	19-file boolean inversion with interface safety rejection
Validation & Safety	validate_edit, validate_edits, shadow_run	✅ Passed	2.00s remote in-memory syntax validation

---

Summary: What This Means for Systems Engineering

Moby’s scale—387K lines of Go orchestrating low-level Linux primitives—demands precision:

• 0% local CPU: Massive builds and language server indexes remain offloaded to LAN cluster nodes.
• Microsecond slicing: Navigating deep containerd task execution pipelines takes milliseconds.
• Interface-safe refactoring: Prevents breaking subtle plugin executor contracts across package boundaries.

Alexander Panasenko (2026-09-30). Moby Under the Microscope: What 67 AST Tools Found Inside Docker's Engine. https://prod.codes/blog/moby-under-the-microscope-67-ast-tools/