Skip to content

Notes: bring state-of-play back to current, and fix what aged - #217

Merged
mgravell merged 1 commit into
mainfrom
notes-refresh
Sep 11, 2026
Merged

mgravell merged 1 commit into
mainfrom
notes-refresh

Conversation

@mgravell

Copy link
Copy Markdown
Member

Notes only - no product or test changes.

state-of-play.md

This is the "read first after a break" page, and it was the most wrong thing in the repo: still listing #206/#207/#208 as in flight with a landing order to follow, and unaware of #209-#216. Rewritten to say what is true - nothing of ours is in flight, and the four open PRs (#167, #153, #151, #84) are all external and all awaiting a decision only you can give.

It also rescues content that existed nowhere in main. The account of why #206 was closed was sitting on the typehandler-registration-note branch in a commit pushed after that PR merged, so it never landed: gating stopped the bridge emitting anything for consumers who did not opt in, but the read-side check still sat in RowFactory.GetValue<T> - the type-flexible arm of every mapped member, ~130 call sites across the goldens - so everyone paid for a feature almost nobody would enable. The emission-time fix that was considered and rejected is recorded alongside it, being the part most likely to get re-proposed.

Two things promoted out of the small print, because they gate real work:

Corrections: #117 and #162 are closed, not awaiting a decision; the type-handler branch harvest was filed as "before #208 settles" and #208 has now settled, so that is due (or a deliberate write-off); diagnostic ids recorded as actually shipped - DAP053 runtime registration, DAP054 unusable handler, DAP055 duplicate, DAP056 Type-based non-goal, next free DAP057.

parity.md

One row had aged out: CommandDefinition still claimed "27 overloads, every one skipped silently". #214 moved the Type+CommandDefinition combinations into the non-goal bucket, so it is now 21 of the 22 rows in that bucket. Reworded to cite the generated report rather than restate a number - which is what #213 was for, and this row was a leftover of exactly the habit it set out to kill.

Dangling links

typehandlers-design.md never existed in main - it was a file on the closed #206 branch - and was linked from README.md, state-of-play.md and parity.md. All three now point at the note that did land, typehandler-registration.md. Every .md link under notes/ now resolves.

`state-of-play.md` is the "read first after a break" page and was the most wrong
thing in the repo: it still listed #206/#207/#208 as in flight with a landing order
to follow, and knew nothing of #209-#216. It now says what is true - nothing of ours
in flight, the four open PRs are all external and all awaiting a decision.

It also absorbs the account of **why #206 was closed**, which was sitting unmerged on
the `typehandler-registration-note` branch and existed nowhere in main: gating stopped
the bridge emitting for consumers who did not opt in, but the read-side check still
sat in `RowFactory.GetValue<T>` - the type-flexible arm of every mapped member - so
everyone paid for a feature almost nobody would enable. The emission-time fix that
was considered and rejected is recorded with it, since that is the part most likely
to be re-proposed.

Two things promoted, because they gate real work and were buried:

- the behavioural harness is local-only and does **not** exist on this machine (no
  `aot-harness` branch, no SQL Server, Windows-shaped repack recipe), so no phase-3
  round can be closed and 677/793 cannot be re-measured until it is rebuilt;
- net48 is unverified since #216 and #214, both of which changed interceptor goldens.

Corrections: #117 and #162 are closed, not awaiting a decision; the `type-handler`
branch harvest was filed as "before #208 settles", and #208 has settled; diagnostic
ids as actually shipped (DAP053-056, next free DAP057).

`parity.md`: the `CommandDefinition` row still said "27 overloads, every one skipped
silently" - #214 moved the `Type`+`CommandDefinition` combinations out, so it is 21
of the 22 in that bucket. Cites the report rather than restating a number, which is
what #213 was for.

Also: `typehandlers-design.md` never existed in main - it was a file on the closed
#206 branch - leaving dangling links in three notes. Pointed at the note that did
land, `typehandler-registration.md`.
@mgravell
mgravell merged commit 20a16b0 into main Sep 11, 2026
2 checks passed
@mgravell
mgravell deleted the notes-refresh branch September 11, 2026 13:35
mgravell added a commit that referenced this pull request Sep 11, 2026
Pre-release verification, and the rig had to be rebuilt first: the old one was
local-only on the Windows box and did not survive the move. The step-by-step for
standing it up from nothing is now at the top of harness-baseline.md, Linux-shaped -
databases from the Dapper suite's own docker compose, the SqlServerConnectionString
env var, the local feed, and the .globalconfig severity downgrades without which
DAP036/DAP037 stop the build outright.

Round 15, net10.0: **729 passed / 800**, 41 failed, against a vanilla control of
770/800 on the same box. Scorecard: handled 432 of 736 enabled call-sites. All 41
divergences are known gaps at x2 providers - TypeHandler, Literal, Misc, Parameter,
Async, plus scattered singles - so no new failure class, and the pass count is up on
round 12's 677.

The question this was run to answer: **the round-12 generator (b411eb4), packed and
run against this same rig, also reads 432 of 736.** So #208-#217 changed interception
not at all, and moved behaviour only upward.

Recorded honestly rather than smoothed over: the 533/725 in round 12 is *not*
reproducible here, and since the round-12 generator does not reproduce it either, the
difference is rig configuration that no longer exists to inspect. DAP051 firing 244
times is the likely candidate but is a hypothesis. The durable lesson is in the note:
absolute call-site counts are rig-specific, so compare within a rig, never across.

Also corrected: the preamble still described round 14's [module: UseRuntimeTypeHandlers]
as part of the setup, and that attribute does not exist - #206 was closed.
@andreasblueher

Copy link
Copy Markdown
Contributor

@mgravell Thanks for all the work you've put in to publish 1.1 much appreciated!

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.

2 participants