26.7.53: typechecker never terminates in `list_alias_members_for_path` — unbounded `index_depth` means a web server silently never starts (26.7.47 is fine)

[logbie]

Summary

Starting with 26.7.53, the typechecker fails to terminate on a large real-world program. The process pins one core at ~100% CPU, grows memory steadily, and never reaches the listen statement — so a web-server program simply never starts, and emits no error at all.

A perf profile puts the hot loop squarely in TypeChecker::list_alias_members_for_path, and reading the code the cause looks structural: ListAliasPath::index_depth is an unbounded usize that add_structural_list_alias keeps re-translating upward, so the alias set can never reach a fixpoint.

This is worse than a hard error, because there is no diagnostic — systemd sees a live process that never binds its port.

Impact

This blocks https://wfl.fyi (Scriptorium CMS, WFL-native TLS) from moving off 26.7.47, which is where it is pinned in production today.

Reproduction

lib/scribe.wfl from the public WebFirstLanguage/wfl-web repo reproduces it on its own — it is self-contained, with no include from:

git clone https://github.com/WebFirstLanguage/wfl-web
cd wfl-web
wfl lib/scribe.wfl

Runtime	Result
26.7.47	exits 0 in well under a second
26.7.53	hangs indefinitely (killed at 60s+), 99.9% CPU, RSS climbing

Same binary, same file, same working directory — the only variable is the runtime.

Running the full site (wfl main.wfl) shows the practical failure: the process stays alive, logs only its usual ANALYZE-* warnings, prints no listening on port line, and never accepts a connection.

Regression range

• 26.7.47 — fine. This is what production runs.
• 26.7.52 — not this bug. It failed differently, with two hard typechecker errors (an outer-scope redeclaration in a try:/when error: pair, and a for each over an Any-typed collection). Both of those are fixed in 26.7.53 — I re-tested both constructs and they now pass. Recorded from a prior run rather than re-verified here, since I no longer have a 26.7.52 binary.
• 26.7.53 — this hang.
• 26.7.48–26.7.51 — untested.

Given the timing, PR #652 ("Codex/typechecker contract audit") is the most likely origin, though I have not bisected commits to confirm.

Evidence — perf profile of the spinning process

perf record -F 199 -g over 6s (1204 samples), release build with debuginfo:

26.32%  hashbrown::map::HashMap<K,V,S,A>::insert
14.27%  core::hash::BuildHasher::hash_one
11.04%  [unresolved] -> wfl::typechecker::TypeChecker::list_alias_members_for_path
 6.09%  wfl::typechecker::TypeChecker::list_alias_members_for_path
 5.19%  core::hash::sip::Hasher::write
 3.61%  malloc

Consistent with an unbounded insert loop into list_alias_groups. Observed RSS went 59 MB → 80 MB over ~35s of spinning, with the main thread parked in futex_wait while a worker thread span.

Where I think it comes from

src/typechecker/mod.rs:145:

struct ListAliasPath {
    binding: SymbolBindingKey,
    index_depth: usize,   // unbounded
}

src/typechecker/mod.rs:1407 synthesizes new paths at a translated depth, with no cap and no visited set:

fn list_alias_members_for_path(&self, path: &ListAliasPath) -> HashSet<ListAliasPath> {
    ...
    for (ancestor, aliases) in &self.list_alias_groups {
        if ancestor.binding == path.binding && ancestor.index_depth <= path.index_depth {
            let offset = path.index_depth - ancestor.index_depth;
            for alias in aliases {
                members.insert(ListAliasPath {
                    binding: alias.binding.clone(),
                    index_depth: alias.index_depth + offset,   // grows without bound
                });
            }
        }
    }
    members
}

and add_structural_list_alias (~line 499) feeds newly-materialized deeper descendants straight back into the same map:

let translated = ListAliasPath {
    binding: target.binding.clone(),
    index_depth: target.index_depth + descendant.index_depth - source.index_depth,
};

If two bindings alias each other at different depths, each pass produces a strictly deeper ListAliasPath, which is a brand-new HashSet key, which then qualifies as a "descendant" on the next pass. Nothing bounds the recursion, so the worklist never converges.

Which construct triggers it

Bisecting lib/scribe.wfl (100 actions) by truncating at end action boundaries, the first hanging prefix ends at line 2322 — scribe_hoist_defs:

define action called scribe_hoist_defs with parameters sc_nodes and sc_ctx and sc_scope:
    for each nd in sc_nodes:
        store k as nd["kind"]
        check if k is "macro":
            store mkey as nd["name"]
            check if scribe_negate of (scribe_scope_has of mkey and sc_scope):
                push with sc_scope and (scribe_binding of mkey and (scribe_macro_value of nd))
            end check
        otherwise:
            check if k is "import":
                store ig as scribe_do_import of nd and sc_ctx and sc_scope
            ...

The self-nesting shape looks like the aggravating factor. scribe_do_import pushes into sc_scope a binding whose value is a map holding binds — and binds is itself a list of bindings of the same shape as sc_scope:

store binds as scribe_macro_bindings of nds
create map nsval:
    "__scribe_ns__" is yes
    "binds" is binds
end map
push with sc_scope and (scribe_binding of alias and nsval)

So sc_scope transitively contains lists of the same shape as sc_scope — exactly the cyclic alias relation that would let index_depth climb forever.

I could not reduce this to a short snippet. Several hand-written candidates (pushing into a parameter list inside a for each, pushing values derived from the loop variable via nested calls, and the self-nesting binds-inside-scope shape above) all typecheck fine in isolation on 26.7.53. That suggests the blow-up needs a critical mass of interacting alias edges accumulated across the whole ~2374-line file rather than one construct — which may itself be a useful clue about where the fixpoint is missing.

Suggested fix

Whatever the specific trigger, the unbounded index_depth looks like the thing to fix:

1. Carry a visited set through add_structural_list_alias / list_alias_members_for_path so a cyclic alias relation cannot be re-expanded forever.
2. And/or cap index_depth at a saturating maximum — beyond a small depth the extra precision is unlikely to change a diagnostic.
3. A hard iteration ceiling on the alias fixpoint, degrading to a conservative "may alias" answer, would turn any remaining non-convergence into a bounded slowdown instead of a hang.

Regardless of the root cause, it would help a great deal if a typechecker that fails to converge timed out with a diagnostic rather than hanging silently. A web server that never binds and never explains why is very hard to diagnose in production.

Environment

• Ubuntu 24.04, x86_64, 2 vCPU / 8 GB
• wfl built from source, cargo build --release (optimized + debuginfo)
• Compared against 26.7.47 built the same way on the same machine

[logbie]

Confirmed, and the origin is now pinned rather than suspected. Verified by reading the tree at main (69c1c1e4, v26.7.53) — no local build, so the runtime claims below are source/history evidence, not a reproduction.

Origin: PR #652, exactly. git log -S --reverse on src/typechecker/mod.rs returns a single commit for each of struct ListAliasPath, fn list_alias_members_for_path, and fn add_structural_list_alias — all three first appear in 48c46423 ("Codex/typechecker contract audit", #652, +6264/−913 in that one file). Your reading of the mechanism holds at main: the struct at :147 carries an unbounded usize, :516 synthesizes target.index_depth + descendant.index_depth - source.index_depth, and :1423 synthesizes alias.index_depth + offset. Neither site has a cap or a visited set, and both feed straight back into list_alias_groups, so a binding that transitively aliases itself at a different depth has no fixpoint. list_alias appears 165 times in the file — the relation is load-bearing, which is why this shows up on a real program and not in the corpus.

The 26.7.48–26.7.51 gap can be closed without testing it. None of this machinery existed then. The bump to 26.7.52 is 6d286e8, 2026-07-26 10:20:30Z; #652 merged 2026-07-27 04:38Z, after it. So the affected range is precisely "anything built from 48c46423 or later," and 26.7.48–26.7.51 are clean by construction.

One trap worth flagging, because it bites the obvious fallback. Two different code states both report 26.7.52, and the published one is the bad one: nightly-2026-07-27 ships wfl-26.7.52.msi built from 48c46423, i.e. a "26.7.52" that does contain #652 and does hang. Your two-hard-errors 26.7.52 must have been a pre-#652 build. Concretely, git diff 48c46423..69c1c1e4 touches only src/version.rs under src/ — the rest is CI, docs, and the toolchain test from #653 — so 26.7.53 and the released 26.7.52 are typechecker-identical. Two consequences: the last hang-free published nightly MSI is nightly-2026-07-21 / wfl-26.7.47.msi (which is what wfl.fyi is already pinned to, so the pin is correct), and stepping "back" to the 07-27 nightly would not help. It also means #652 both fixed the two hard errors you hit and introduced this hang.

On the shape of the fix in #655. Bounding index_depth is the right lever — it makes the key space bindings × depth finite, which is what buys the fixpoint, rather than papering over it with an iteration cap. The asymmetry is the part I'd want a reviewer's eye on and it's already argued in the code: the relation drops over-deep paths (a clamped Replace could pin an unrelated depth to a narrower type) while the effect path clamps and downgrades to Escape, on the grounds that silently dropping a real mutation leaves an aliased aggregate holding a stale narrow element type. Escape widens to Any, so the failure mode is lost precision, never a spurious rejection — that's the correct direction for the backward-compatibility rule, since no program that checks today can start failing.

Two follow-ups I'd suggest:

1. MAX_LIST_ALIAS_INDEX_DEPTH = 8 deserves a guard, not just a comment. The justification (deepest real path in TestPrograms/ is 2) is measured, but it's measured once. A debug assertion or a corpus test that fails if any acyclic program reaches the bound would turn "8 is roomy" into something CI keeps true — otherwise the first legitimately deep aggregate silently degrades to Any with no signal.
2. A hang is a worse diagnostic than an error, independent of this bug. The ExecutionBudget work in feat: add shared ExecutionBudget consolidating runtime resource caps #609 already established the pattern; a wall-clock or iteration budget on typechecker fixpoint loops would convert the next non-converging relation into a diagnostic instead of a systemd service that never binds its port. Worth its own issue — this bug is the argument for it.

Suggested labels: bug, typechecker, regression, severity:high.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Fixed by #655, merged to main as fe42f06. Closing.

Root cause

Confirmed as suspected: git log -S puts both add_structural_list_alias and the depth-translation loop in list_alias_members_for_path in 48c4642 — PR #652, the typechecker contract audit. Nothing before it created a translated index_depth.

The diagnosis in the report was right, and here is the precise mechanism. Both functions synthesize alias paths at a translated depth rather than only reading existing ones:

• list_alias_members_for_path re-reports every ancestor relation at alias.index_depth + offset.
• add_structural_list_alias materializes descendants at target.index_depth + descendant.index_depth - source.index_depth.

That is correct for a tree and non-terminating on a cycle. When a binding transitively aliases itself at a different depth, each translation yields a strictly deeper path → which is a brand-new HashMap key → which qualifies as a "descendant" on the next pass. The relation's key space was bindings × ℕ, so there was no fixpoint to converge to. Hence HashMap::insert at 26% of your profile.

The silence has a separate cause worth recording: the growth happens within a single statement, so the run-budget poll in check_statement_types never got a turn between statements. That is why there was no diagnostic rather than a slow one.

It reduces to three lines

You suspected this needed "a critical mass of interacting alias edges accumulated across the whole ~2374-line file". It doesn't — bisecting on push count:

store scope as [1]
push with scope and scope
push with scope and scope

One self-push always terminated; two never did. Your binds-inside-sc_scope shape is the same cycle drawn through a map (list → map → list), which is why no individual statement in scribe.wfl looks suspicious. Measured directly, depth reached 2081 after 64 applications and was still climbing.

Solution

Of your three suggestions, (2) is what shipped — MAX_LIST_ALIAS_INDEX_DEPTH = 8, enforced at the three chokepoints where a path can enter or escape the relation. That makes the key space finite, so convergence is structural rather than merely faster.

The bound is measured, not guessed. It cannot come from the static type, because Type::Any makes type_at_alias_path answer at every depth — a gradually typed program supplies no ceiling. Instrumenting add_list_may_alias_edge across the whole TestPrograms/ corpus put the deepest path any acyclic program reaches at 2, so 8 leaves 4× headroom. The constant is also load-bearing for cost: a saturated cyclic relation runs roughly its fifth power, so 16 still left a twelve-line program at 14s where 8 takes 452ms.

The part that took a second pass is worth flagging, because it is the subtle half:

• Relation keys past the bound are dropped. A clamped key would let ListMutationEffect::Replace pin an unrelated depth to a narrower type.
• Mutation effects past the bound are clamped and applied as Escape, not dropped. Review caught that dropping the effect too breaks valid programs, and it reproduces: ten nested lists, a view extracted from the outermost, a push one level past the bound, and reading back through the original path is rejected with "Cannot assign value of incompatible type" for a widening the program performed legally. Nesting past the bound is still finite structure, not a cycle — the aggregate really was widened, and the checker was left holding a stale Number element type. Widening the deepest tracked ancestor to Any subsumes whatever the mutation would have done further down, and Escape being the most permissive effect means this can only cost precision.

Your (1) and (3) were not needed: a visited set still permits unbounded depth, and an iteration ceiling degrading to may-alias is unreachable once the key space is finite.

On the timeout diagnostic

Deliberately not added, and I want to be explicit since you asked for it directly. With a finite key space, non-convergence is now structurally impossible, so a convergence timeout would be unreachable code. The existing per-statement budget poll is the remaining safety net — and it works again now that each statement terminates. If a future change reintroduces unbounded synthesis, the regression tests below fail rather than hang, which is the guard that actually pays.

Verification

	Before	After
lib/scribe.wfl (your repro)	hang, killed at 60s+	553 ms, exit 0
3-line minimal repro	hang	19 ms
12-line list/map/list cycle	hang	452 ms
Alias-depth integration tests	3 × 30s timeout	0.07 s, 8 pass
Lib unit tests	509 s, 2 failing	3.1 s, all pass

Regression evidence across the whole TestPrograms/ corpus: I built the pre-fix binary and diffed every program's exit code against the fixed one. Exactly one line differs — the new cycle-termination program going 124 → 0. Every other result is identical on both binaries.

Tests ship at three layers with Red evidence committed first. The design point that makes them a durable gate: they fail cleanly rather than hang if the bound regresses — the integration tests run the checker on a worker thread under a deadline, and the unit tests assert the relation reaches a fixpoint instead of trying to simulate the runaway. Two negative-direction tests guard the other side, so the bound can't be "fixed" by simply tracking less: deep acyclic nesting must still typecheck with zero diagnostics, and a mutation below the bound must still reach the original aggregate.

wfl.fyi should be clear to move off 26.7.47 on the next build.

---

Generated by Claude Code