Repository navigation
Darling/README.md says twelve PostgreSQL read tools and there are thirty-two, which is the third hand-maintained count found stale tonight #3072
Description
Activity
Claude posting for Erik Darling
This issue's diagnosis was wrong, and the sweep found the better one. Recording it here because the framing decides the fix.
I called it "off by 20." It is not. The twelve tool-family numerals each count the tools named in their own bullet, and ten of the twelve were internally accurate. "Twelve" correctly counts a twelve-item list. What went stale is the list, which stopped being the read surface somewhere on the way to thirty-two.
So correcting the digit would have produced a numeral contradicting a visibly shorter list — strictly worse than leaving it, not temporarily right. The recurring defect is not a stale number. It is a partial enumeration with a numeral frozen to it.
The policy that came out of it is a third option neither of us proposed
Classify by what the numeral is doing:
- Class A — restates a list in the same sentence → delete the numeral. The twelve tool bullets, the viewer's sub-tab/grid/chart/lane counts. The list is the content; the count adds nothing and is the only part that can rot.
- Class B — an independent fact about the code → correct it AND pin it against
CollectorCatalog.All/TimescaleSupport.HypertableCount. - Class C — frozen artifact content or a past measurement → leave it, with the reason stated. The V4/V5/V6 view counts are literal SQL inside immutable migration rungs; "correcting" them would falsify the rung.
The clincher for Class B is the sharpest evidence in the whole sweep.
build.ymlandnightly.ymlcarry the CI worker-sizing numbers, andCiClusterWorkerSizingTestsenforces them at 72/83. The README's copy of those same numbers read 57/68. One was guarded, one was not, and only the guarded one was right. That is the argument for pinning, made by the repo rather than by anyone's judgement.Some of the measured drift
site claimed measured Darling:748 / 41 / 7 collectors 69 / 42 / 27 :83257 and 68 workers 72 and 83 :717V1all 54 tables 69 :520Twelve read tools 12 named / 32 real :504Twenty 21 — stale against its own sub-bullets root :217,:353Lite 77 tools 87 And a claim that was outright false rather than stale:
:693said "Every one of the twelve has an MCP tool." Not ondev—pg_plan_capture_readinesshad no read, which is exactly what #3071 adds. Naming it as the exception would have gone stale the moment that merged, so the universal is gone instead.Three failures worth more than the fixes
Two of the sweep's own greps were wrong first. A file-level
!IsAzureSqlDbscan reported 14 against a true 6; a bullet-scoped regex over-captured prose cross-references, reporting 5 and 3 where the truth was 3 and 2. Both would have been published as findings — and both were the same defect this issue is about, one level up. The figures were re-taken from anet10.0harness over the realPerformanceMonitor.Collectorsand.Darling.Storageassemblies rather than from text matching.The class-A pass skipped the reported site. It hit eleven of twelve bullets and missed the PostgreSQL one — the very site this issue names. The script printed "applied 11" while the commit message said twelve. Caught by re-reading the rendered prose, not by any assertion.
And the new pin would have shipped with the defect it prevents.
Darling/**/!(*.md)excludes the one file the pin parses, so a README-only edit would never have run it. A guard that cannot fire on the thing it guards. Fixed by addingDarling/README.mdto the filter at all three sites, with the same reasoning as the adjacentnightly.ymlentry.Not verified
The xUnit runner itself and the rest of
Darling.Tests; the viewer counts came from XAML and the PostgreSQL tab registry rather than a running viewer; the--test-connectiontranscript is derived through the real gate rather than captured live. And "fixed aggregate tabs" is genuinely ambiguous — 5, 6 or 7 depending on gated and hidden tabs — so the prose now avoids counting it at all, which is the honest answer rather than picking one.Claude posting for Erik Darling
Fixed by #3073, merged to
devas987c005c9bb. Closing by hand — a closing keyword in a PR body does not fire when the PR targetsdevrather than the repository's default branch.
Darling/README.md:520says:There are 32
get_pg_*MCP tools ondev— counted from[McpServerTool(Name = "get_pg_…")]declarations — and 33 once #3070'sget_pg_plan_capture_readinesslands. The README is off by 20.The fix worth making is not the number
A hand-maintained count in prose goes stale the moment anyone adds to the thing it counts, and nothing tells you. This is the third instance of that exact shape found in one evening:
DarlingAlertSettings' clamp justification cited "the production worst runs ~7% of cadence" — measured wrong by 53x, and it was the stated reason for a live clamp's floor (Store Job Over Cadence is mis-tuned and mis-worded for the hourly refresh: its remedy changes the materialised window and its default sits one point from firing #3060, fixed in PR Fixes #3060 #3066).TimescaleSupport's drift comment cited 194/225/335 s while the series had since read 594 s — 2.6x the figure it names, within hours (HeaviestHourlyRefreshObservedCeilingSeconds is one sample of a twelve-hour-old regime, and #3035's grid plus a build-time assertion are sized against it #3069).In every case the number was correct when written and became wrong silently. The pattern is what should be fixed, not the digit.
Options, and the cheap one is not the good one
Correct the number. Cheapest, and it will be wrong again after the next tool. It also invites the same fix repeatedly, which is how it got to twelve-versus-thirty-two rather than being caught at thirteen.
Stop counting in prose. "The read surface for a PostgreSQL target's collectors" carries the whole meaning; the numeral adds nothing a reader needs and is the only part that can rot. Deleting one word is a permanent fix.
Derive it.
CrossAppMcpToolInventoryPinTestsand the instructions census already enumerate the tool surface, and this repo has form for asserting a documented figure against the code that produces it — #3047 pinned prose thresholds against the constants they came from for exactly this reason. If the count is worth stating, it is worth pinning; if it is not worth pinning, it is not worth stating.I lean to the second, with the third as the answer if anyone wants the number to stay. What should not happen is a one-digit edit with no guard, because that is the change that has already failed twice here.
Worth checking while in there
Whether other counted claims in
Darling/README.mdandREADME.mdhave drifted the same way — the tool families, collector counts, and any "N tabs"/"N panels" phrasing. A sweep is cheap and this is unlikely to be the only one.Provenance
Found by the #3070 lane while adding the thirty-third tool, and flagged rather than folded into its PR — correctly, since a README sweep is not that change. The 32 count was re-verified here against
origin/dev.