format: add activation correlation id to invoke/return/revert types#241
Merged
Conversation
Contributor
|
The activation-id correction (#240 schema) adds an optional `activation` string on the invoke, return, and revert context objects — the opening invoke and the closing return/revert share the same value to pair an activation independent of trace order. Mirror that in the TS types: add `activation?: string` to Invoke.Invocation, Return.Info, and Revert.Info. Placed per-object to track the schema (activation is added on each of invoke/return/revert, not on the shared context/function identity schema). No guard change — activation is an optional field on an existing object, not a new context discriminator.
gnidan
force-pushed
the
debugger-activation-field
branch
from
b2080ec to
c3248e8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #240 (activation-id spec correction). Closes #34.
#240 adds an optional
activationstring on theinvoke,return, andrevertcontext objects — the openinginvokeand the closingreturn/revertcarry the same value, letting a debugger pair anactivation independent of trace order (disambiguating adjacent inlined
activations and surviving optimizer reordering).
This mirrors that in the TS types: adds
activation?: stringtoInvoke.Invocation,Return.Info, andRevert.Info. Placed per-objectto track the schema exactly — the schema adds
activationon each ofinvoke/return/revert, not on the shared
context/functionidentityschema (so
Function.Identity/isIdentitystay untouched).No guard change:
activationis an optional field on an existing object,not a new context discriminator — the unchanged guards already accept it
(they ignore extra properties). Verified by scratch-merging #240's schema
locally and running the format suite: all guard-vs-example tests pass
with the new
activationexamples present.Merge ordering: land after #240 merges so the types track the merged
schema. No file overlap with #240 (this touches only
packages/format/.../context.ts; #240 touches schemas + mdx), so noconflict either way — this is purely a don't-land-types-ahead-of-schema
courtesy.
Note (reviewer's call): every other optional field on these objects is
validated in its guard (e.g.
identifier/data/successdo an optionaltypeof/pointer check), so strictly for consistencyactivationcouldget a one-line
(!("activation" in v) || typeof v.activation === "string")in
isInvocation/Return.isInfo/Revert.isInfo. Left out per architect's"no guard changes" call; happy to add if you'd prefer the consistency.