How this codebase does concurrency

Your last stated gap. Go's concurrency reputation is intimidating, but this codebase uses a small, repeated vocabulary — four patterns cover almost everything, and one primitive, context, ties them together. You've already read every one of these goroutines in earlier lessons; now we name the patterns so you can read any of them.

Pattern 1 · The ctx-cancellable loop (every long-runner)

Every periodic component — the at_risk scheduler (L23), the oracle bridger (L27), the validator tiers (L34), the lease keepalive (L37) — is the same shape: do work, then select between "time to go again" and "we've been cancelled."

for {
    doWork(ctx)
    select {
    case <-ctx.Done():            // cancelled (shutdown) → return cleanly
        return nil
    case <-time.After(interval):  // the tick → loop again
    }
}

Pattern 2 · Bounded fan-out + WaitGroup join

Parallel I/O — N independent RPC reads at once — is readAllFeeds (L26). Pre-allocate a result slice, launch one goroutine per item, each writing its own slot, then wait for all:

out := make([]navlinkReadResult, len(bindings))   // one slot per task — no shared write
var wg sync.WaitGroup
for i, b := range bindings {
    wg.Add(1)
    go func(i int, b candidateBinding) {   // i, b passed as ARGS — capture safety
        defer wg.Done()
        out[i] = readOneFeed(ctx, b)            // each goroutine owns out[i] exclusively
    }(i, b)
}
wg.Wait()                                       // block until all N finish

Pattern 3 · Isolate a risky task — goroutine + timeout + recover

When one unit of work might hang or panic and must not take down the loop, run it in a goroutine under a deadline and turn its failure into data. The validator's per-check runner (L34) is the template:

checkCtx, cancel := context.WithTimeout(ctx, timeout)   // a child ctx that auto-cancels after `timeout`
defer cancel()
done := make(chan result, 1)                       // buffered: the goroutine never blocks sending
go func() {
    defer func() { if r := recover(); r != nil { out.panicVal = r } }()  // catch a panic → value
    out.findings = check(checkCtx, deps)
    done <- out
}()
select {
case out := <-done:          // finished (maybe with a recovered panic) → emit CHECK_PANIC finding
case <-checkCtx.Done():      // timed out → emit CHECK_TIMEOUT finding, move on
}

Pattern 4 · A Mutex for shared state (when you don't need channels)

Not everything needs channels. When the requirement is simply "only one of these at a time," a plain sync.Mutex is right — HeavyMu (L31) serializes the heavy risk computers so 7+ don't thrash memory:

HeavyMu.Lock()
defer HeavyMu.Unlock()
runHeavyCompute()    // only one heavy job holds the gate at a time

The thread through all four: context

Notice ctx is the first argument to nearly every function in this codebase. That's the Go convention, and it's load- bearing: a context carries cancellation (Done channel), deadlines (WithTimeout), and request-scoped values (trace IDs, L11) down the call tree. The four patterns are really four ways of reacting to one context — loop until it's done, fan out under it, time-bound a child of it, or guard a resource while honoring it. Learn to follow ctx and you can follow the concurrency.

What you can now do

• Recognize the ctx-cancellable for { work; select { ctx.Done / tick } } loop as the shape of every long-runner.
• Read a fan-out: own-slot writes (no mutex), WaitGroup join, and args-not-closure loop-variable safety.
• Explain isolate-with-timeout-and-recover (WithTimeout child ctx, recover-to-value, buffered done channel).
• Choose a sync.Mutex for in-process "one at a time" and a distributed lease across pods, and say why.
• Follow context as the cancellation/deadline thread under all four patterns.