Skip to content

The fanout block publishes the slowest item's share of the pass (#3502) - #3507

Merged
erikdarlingdata merged 1 commit into
devfrom
fix/3502-fanout-share
Sep 17, 2026
Merged

erikdarlingdata merged 1 commit into
devfrom
fix/3502-fanout-share

Conversation

@erikdarlingdata

Copy link
Copy Markdown
Owner

Closes #3502 — ceremonially; the watcher closes it at merge.

The metric was honest; the guidance read it as a verdict

fanout.dominance is the slowest item measured against the mean item, and the tool description told readers to treat it as a concentration verdict — "near 1.0 = width, around 2.0 or above = one database dominates." The #3477 reporter's evidence broke that reading cleanly: their two instances score 3.58 and 4.20 — near-neighbours, both far past the old bar — while the slowest item's actual share of the pass sits 5.6x apart (4.97% at 72 items, 27.98% at 15). At width, dominance can't say whether one database is worth chasing; the number the remediation decision turns on is the slowest item's share of the whole pass, which was one division away and never published.

What ships

slowest_share_pct joins the fanout block on both SKUs — the block is an engine-shared twin whose descriptions and payloads are pinned byte-identical, so a one-sided fix was structurally impossible — computed as a derivation from dominance (dominance ÷ items), so the two figures agree by construction and null exactly together. Dominance stays: it still answers how even the fan-out is; it just can't say whether the worst database matters, and its doc now says so. The description routes the width-vs-concentration decision through the share, with the reporter's counter-example compacted into the doc as its permanent warning label, and the retired verdict sentence is pinned absent so it can't drift back in.

Tests

The counter-example as a fact (both instances, the dominance-of-10-at-72-items limiting case, share = 100 when the slowest is the run, and a same-inputs derivation pin over every row); the two-shapes arm re-routed through the share; the no-fanout arm reporting nothing rather than zero; the description pins (share formula present in both SKUs, retired guidance absent, and the emission wiring pinned in both anonymous objects — the mutation-invisibility lesson). Plus share asserts on the existing live-store round-trip. Credit for the derivation, the counter-example, and the publish-the-number-the-decision-turns-on framing belongs to the #3477 reporter, verbatim in the CHANGELOG.

Tests cannot run on macOS; verified by full-solution build and static tracing. CI is the first execution, review-dark per the known window.

@erikdarlingdata
erikdarlingdata enabled auto-merge (squash) September 17, 2026 12:45
…verdict dominance was being read as (#3502)

get_collection_health's per-collector fanout block published dominance -
slowest_ms * items / run_ms, the slowest item against the MEAN item - and
the tool description told readers to take the width-versus-concentration
decision on it: near 1.0 the cost is width, around 2.0 or above one
database dominates. That reading is numerically wrong at width, because
the ratio's ceiling is items: at 72 databases, even a dominance of 10 is
one database holding 14% of a pass. The #3477 reporter's evidence proved
it with two instances scoring 3.58 (72 items) and 4.20 (15 items) -
near-neighbour scores the guidance calls the same shape, whose slowest
items' shares are 4.97% and 27.98%, 5.6x apart and wanting opposite
remedies.

The block now carries slowest_share_pct - slowest_ms / run_ms, which is
dominance / items - the one-division-away number the decision actually
turns on: low share means width and bounded parallelism is the lever,
high share means one database dominates and a per-database schedule
override or a stagger reaches exactly it. dominance stays for continuity
as the evenness ratio - it is not wrong, it is just not a verdict.

The share is DERIVED from dominance (share = dominance / items) on both
SKUs' row models rather than recomputed from the columns, so the two
figures can never drift apart or describe different runs, and it is null
exactly when the fanout block is null - never a 0% that would read as
"perfectly even" on a run that reported nothing. No schema change: the
V80 columns already carry everything the share needs.

Both SKUs move together because BothSkusToolDescriptions_StayByteIdentical
holds the two descriptions to one contract: the corrected guidance routes
the decision through the share and carries the two-instance
counter-example as the permanent warning label, pinned alongside the
field's wiring in CollectionLogFanoutRollupStoreTests (the anonymous-object
emission no behavioural test reaches - the #3010 lesson). The V80 rung
test keeps its two-shape arithmetic and now separates them by share; the
new counter-example test pins the wide instance, the issue's
dominance-of-10 limiting case, the share-saturates-at-100 endpoint, and
the derivation itself, so a future edit that recomputes either figure
from different columns fails loudly. The store round-trip asserts the
share off real V80 columns beside the dominance it already read.

Credit: the derivation, the counter-example, and the "publish the number
the decision turns on" framing are the #3477 reporter's, verbatim from
their evidence comment.
@erikdarlingdata
erikdarlingdata merged commit 6295459 into dev Sep 17, 2026
7 of 8 checks passed
@erikdarlingdata
erikdarlingdata deleted the fix/3502-fanout-share branch September 17, 2026 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant