Four places answered version 1.0.0, five READMEs installed 12.8.0, and a probe pinned the weather

[dmitrat]

Three near-zero items from Docs/FIX-PLAN-FROM-SITE-FINDINGS-2026-08-15.md, each verified by execution before it was touched.

The version, in four places

	answered	read by
SELECT VERSION()	1.0.0	anyone checking what they are running
WitDbConnection.ServerVersion	1.0.0	every ADO.NET consumer
DataSourceProductVersion	1.0.0	tooling and ORMs, through GetSchema
DataSourceProductVersionNormalized	01.00.0000	the same, compared as a string

Every package is on 13.1.1. The finding named three; the fourth came out of looking for the rest. Four separate literals, four independent ways to go stale, and nothing that could notice.

WitDatabaseVersion reads the assembly's informational version — which is what the csproj's <Version> becomes — cut at the + the SDK appends the commit sha after, and normalises it to the padded shape DataSourceProductVersionNormalized exists to be compared in.

The guards read the assembly independently of the property under test. A case carrying "13.1.1" in its own text would be the same defect one layer out: it would pass today and need editing at every release, which is exactly how four literals survived thirteen major versions. Each carries a control that the assembly is not itself reporting 1.0.0, or the comparison would pass for the wrong reason.

All four sites were measured red separately — each names its own place:

Failed SelectVersionAnswersTheSameTest              Expected: "13.1.1"  But was: "1.0.0"
Failed ServerVersionIsTheEnginesVersionTest         Expected: "13.1.1"  But was: "1.0.0"
Failed TheSchemaRowsToolingReadsCarryTheSameVersion  Expected: "13.1.1"  But was: "1.0.0"
                                                     Expected: "13.01.0001"  But was: "01.00.0000"
Failed EvaluateVersionTest                          Expected: "13.1.1"  But was: "1.0.0"

The READMEs, and the rule found more than the finding named

A README ships inside the NuGet package, so it reaches people who never open the repository, and the first thing they copy out of it is the PackageReference. The finding named one file with three pins. The rule over every README under Sources/ found eight, across five packages, all on 12.8.0.

The Core README also still sold the claim the 11 August measurement retired — "LSM-Tree (write-optimized)", in three places. It carries the numbers now: with MVCC on, which is the default, the LSM store pays about 50x and the B+Tree 1.5–2x; the comparison the old claim described is the one with MVCC=false.

EveryInstallSnippetNamesTheVersionThatShipsTest compares each pin against the version its own project declares, counts the eight it examined so that "nothing left to find" cannot read like "the folder moved", and goes red with a single pin put back:

OutWit.Database.Parser/README.md installs OutWit.Database.Parser 12.8.0; the package is 13.1.1

The probe that reddened CI for saying too much

SecondaryIndexConcurrencyProbeTests.ProbeConcurrentAddOverABareIndexStoreTest asserted that the second writer's key was among the missing ones — one shape of the damage — while its own remarks say the shape varies.

It failed on 2026-08-15 on a branch touching no engine code and passed on a re-run of the same commit. On a loaded runner the second writer missed the two-second window, landed after the release, and its own entry survived — while 207 of the first writer's were lost. The damage was real and larger than usual; the case failed for having said in advance whose entry would go.

It now asserts what it can measure on a machine whose scheduling it does not control — that two writers in one leaf split damage the index — and reports the shape instead of pinning it.

Core 2371, Engine 2543, ADO.NET 1047.

🤖 Generated with Claude Code