The highest-scoring function in tower is stress in tower/tests/balance/main.rs, with an activity-weighted risk score of 16.75, and it hasn’t been changed in 352 days. That is the archaeology problem in this repository: 38 of 619 functions sit in the structural debt quadrant, and poll_ready in tower/src/reconnect/mod.rs has gone 1565 days without a change while carrying 26 independent execution paths. I read this as accumulated maintenance cost rather than an emergency, because whoever next touches these functions inherits the full structural cost at once. Of the 12 critical functions in the tree, only one in my top five is actively changing: poll_ready in tower/src/balance/p2c/service.rs.
The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).
Top 5 Hotspots
| Function | File | Risk | CC | ND | FO |
|---|---|---|---|---|---|
stress | tower/tests/balance/main.rs | 16.7 | 41 | 8 | 26 |
poll_ready | tower/src/reconnect/mod.rs | 12.2 | 26 | 3 | 5 |
poll | tower/src/retry/future.rs | 11.6 | 15 | 4 | 5 |
poll_next | tower/src/util/call_all/common.rs | 11.4 | 14 | 3 | 5 |
poll_ready | tower/src/balance/p2c/service.rs | 11.1 | 13 | 3 | 6 |
619 functions analyzed
High cyclomatic complexity — many independent execution paths, each a potential bug surface and required test case.God Function×2God Function
Calls an unusually large number of distinct functions (high fan-out), making it the structural centre of gravity for a subsystem.Long Function×2Long Function
Function body is too long to review in a single pass; likely contains multiple distinct responsibilities.Stale Complex×2Stale Complex
High structural complexity but untouched for a long time — structural debt that will bite whoever opens it next.Exit Heavy×2Exit Heavy
Multiple return or throw paths dispersed through the body — each exit needs separate test coverage.Deeply Nested×1Deeply Nested
Control structures nested 4+ levels deep, making it hard to reason about the full execution state at inner branches.
The quadrant split was the first thing I noticed. Of 619 functions, 578 are low-risk and inactive, 38 are complex but dormant, 2 land in the live-risk quadrant, and 1 sits in the watch quadrant. A small active surface sits on top of a much larger pile of untouched complexity. None of this says the code is wrong. It says that when someone does need to modify these paths, the cost of understanding them will be paid all at once.
Two of the five functions below are polling state machines in the Future and Service style (poll_ready in the reconnect module, poll in the retry future), and a third is a stream implementation. Rust async code of this shape leans on pinning, projection, and a loop that re-enters a match on state. Ownership and lifetime mechanics in code like this can hide risk that cyclomatic complexity understates, so I read the CC figures below as a floor.
stress — main.rs
I would start with stress because it packs 41 execution paths, 8 levels of nesting, and a fan-out of 26 into one function, and it hasn’t been changed in 352 days. It is a randomized test that drives the p2c Balance service through 100,000 iterations of adding services, readying them, and sending requests. In the excerpt I can see nested random branches that choose between readying a service, using one, adding one, and removing one, with bookkeeping counters and a retired-services list tracked by hand. The ND of 8 is the strongest signal: a reader has to hold the whole decision tree in their head to know what state the counters are in at any given line.
The flagged patterns (complex branching, deeply nested, god function, long function, stale complex) all point the same way. The file has 4 total commits, no bug-linked commits, no reverts, and a bug-fix rate of 0%, so I frame this as maintainability debt rather than a defect signal. Pull request reviews on this file average 1.67 comments each, so reviewers have said something about it. My recommendation is extract-method: pull the ‘ready a service’, ‘use a service’, ‘add a service’, and ‘remove a service’ branches into small helpers that take the shared state as a struct. That alone should take nesting from 8 to roughly 3. Because the test is randomized, a failure is hard to reproduce, and a flatter structure makes a failing seed far easier to diagnose.
poll_ready — reconnect/mod.rs
This is the oldest critical function in my top five: 1565 days since last change, 26 execution paths, yet a modest nesting depth of 3 and fan-out of 5. The excerpt shows a loop over a three-state machine (idle, connecting, connected) with several early returns and a break on connection error. That is the exit-heavy pattern. Every return and break is another path a test has to cover, which is why CC reaches 26 while nesting stays at 3.
The file has 3 total commits, a bug-fix rate of 0%, and no reverts, so the signal is structural rather than historical. One detail I would flag for the next developer: a failed connection sets the stored error and breaks out of the loop, but the function then returns a ready result, with the error surfacing later in call. The metrics can’t tell me whether that is intended, but a two-step handoff like this bites people who don’t know the file. I would split each state arm into its own small method returning a step result, so the loop body becomes a short dispatch and each transition can be tested on its own.
poll — future.rs
The retry future’s poll has 15 execution paths and a nesting depth of 4, and it hasn’t been changed in 1398 days. It drives a three-state machine (called, waiting, retrying) inside a loop and consults the retry policy after each response. The excerpt includes a long comment explaining an assumption that poll_ready on the retry wrapper is equivalent to poll_ready on the inner service, made to avoid adding an Unpin bound to the policy. I take that comment as a sign that the function holds a deliberate design compromise, which makes it a poor candidate for casual cleanup.
The file has 4 total commits, no bug-linked commits, and a bug-fix rate of 0%. Review comment density is 2.0 per review, the highest of the five. Reviewers clearly engaged with this code, and I weigh that as a reason for care, not for a rewrite. My recommendation is narrower than for the others: before touching it, write the state transitions down as a table in a doc comment, then move the ‘decide whether to retry’ branch into its own function. The pinning and projection constraints limit how far this can be split, so I would aim for a smaller win here.
poll_next — common.rs
poll_next in the call-all utility has 14 execution paths and has gone 698 days without a change. It is also the only function in my top five whose file carries a nonzero bug-fix rate: 50% across 6 total commits, with no bug-linked commits and no reverts. The signal is file-level, so I would not read it as proof of a defect in this function, but it does mean the file has seen fix-style work before, and that raises my review priority above the other dormant functions.
The excerpt shows a loop that drains completed responses, checks an end-of-stream flag, pulls the next request, checks the service for readiness, and finally dispatches. Several continue, return, and ready! exits make this the exit-heavy pattern again. One comment notes that the end-of-stream flag is set after a readiness error so the service is not called again. That is an ordering dependency a refactor could easily break. I would name each phase of the loop (drain responses, fill the request slot, dispatch) as its own helper, keeping the control flow in poll_next while moving the bodies out.
poll_ready — service.rs
This is the only live-risk function in my top five. Its activity-weighted risk score is 11.09, it was touched once in the last year, and it was changed 0 days ago. A CC of 13 is lower than the others, but this is the one being edited now, so any change lands on code that already has several nested decision points. The excerpt shows the function first reconciling discovered services, then promoting pending ones to ready, then looping to validate a previously selected index or pick a new one using power-of-two-choices selection. The comments mention that an eviction can reorder the ready set via swap_remove and leave a cached index pointing at a different endpoint.
That comment points at a correctness dependency between this function and the discovery-update logic it calls. The file has 7 total commits, a bug-fix rate of 14%, no bug-linked commits, and no reverts. I would not call that a defect signal, but a recent change about a stale cached index is a reminder that correctness here depends on state shared across several functions. I would review this function together with its discovery-update helper and keep the index-reset invariant covered by a test.
What I would do first
The order I would work in: first, flatten stress before anyone has to debug a failing seed. Second, review the p2c poll_ready while it is fresh in the maintainers’ heads. Third, add transition tables to the reconnect and retry state machines, since those have gone over three years without a change and the context for their design is the part most likely to be lost. In the context-only list, poll in tower/src/buffer/worker.rs (flagged as a god function and stale complex) belongs in the same queue after those.
Patterns Found
Antipatterns detected across the top functions in this snapshot:
| Pattern | Occurrences |
|---|---|
complex_branching | 2 |
god_function | 2 |
long_function | 2 |
stale_complex | 2 |
exit_heavy | 2 |
deeply_nested | 1 |
These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.
See more analyses with these patterns: complex_branching, deeply_nested, exit_heavy, god_function, long_function, stale_complex.
Reproduce This Analysis
git clone https://github.com/tower-rs/tower
cd tower
git checkout df06d70dbea345facbffb5881fe8647f53bf424d
hotspots analyze . --mode snapshot --explain-patterns --forceTo run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.
I use Hotspots to highlight structural and activity risk — not “bad code.” I treat these findings as a prioritization aid, not a bug predictor. Editorial policy →