Repository navigation
[15.x] Emit the context check for the containing type map in CollectionMapper - #4676
Merged
Merged
Conversation
CollectionMapper emits the OverMaxDepth check from the containing type map (memberMap.TypeMap) but decided whether to emit CheckContext from the element type map. When the containing map has MaxDepth set and the element map is plain, the generated plan calls context.OverTypeDepth against the default context, which throws "Context.Items are only available when using a Map overload that takes Action<IMappingOperationOptions>!". Collection execution plans are cached per type pair and MapRequest equality ignores MemberMap, so the first member map to compile a given collection pair wins the cache for every other call site. Once a map with MaxDepth compiles the plan, unrelated callers reaching it under the default context fail, which makes the failure depend on warmup order rather than on configuration. This became reachable for many more configurations when self-referential type maps started defaulting to MaxDepth 64 in 0afaf1e. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wm2m61jXrAs4FheXR5TufH (cherry picked from commit 179a97b)
…4657) (#4675) Reproduces #4657, already fixed by #4651. Unlike that fix's test, this needs no MapAtRuntime and a single Map call: cycle detection turns the collection members into runtime calls, WorkItemModel.Stories compiles the shared List<StoryEntity> -> List<StoryModel> plan with WorkItem's MaxDepth check, and EpicModel.Stories then reuses it under the default context. Registering InitiativeEntity -> InitiativeModel first is what makes the Epic members runtime calls, so the test covers both registration orders. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit df65f2e)
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
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
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.
Backports #4651 (fixes #4650) and its follow-up regression test from #4675 (#4657) to
release/15.x.15.x has the automatic
MaxDepth = 64for self-referential type maps from the CVE-2026-32933 fix, but not theCollectionMappercontext guard. As a result, ordinaryMap<T>(source)calls can throwContext.Items are only available when using a Map overload that takes Action<IMappingOperationOptions>!, depending on registration or warmup order.Both commits cherry-picked cleanly (
-x):CollectionMaxDepthContextandRegistrationOrderMaxDepthContextboth fail onrelease/15.xbefore this change and pass after it.🤖 Generated with Claude Code