[Sunhy (Shy7777)]

Motivation & Context

A record with an auto-generated id works when the key is omitted, but the upsert tool rejects the same record when it includes "id": null. That is easy to encounter when serializing a model whose optional key defaults to None, even though direct collection upserts already accept that value.

Description & Review Guide

• What are the major changes? The upsert tool preserves a null auto-generated key for dictionary records and typed records whose key annotation accepts None. Its record schema uses the same nullability decision, including constructor-defined models with conflicting ordinary class annotations.
• What is the impact of these changes? These records can use the collection's existing key-generation behavior. Supplied keys are still validated, and non-nullable model fields and non-auto-generated keys retain their validation. Get/delete tools are unchanged.
• What do you want reviewers to focus on? The distinction between an auto-generated nullable key and a required or non-nullable key. Regression cases exercise ordinary FunctionTool.invoke, verify the stored records, and cover omitted, null, supplied, and invalid keys. The 573 related core and MongoDB tests pass, including omitted and null ObjectId keys; the full repository and service-backed integration suites were not run. Changed-file type checks pass, while a broader core source check remains blocked by missing optional dependencies and findings in unchanged modules.

Related Issue

Fixes #8625

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Eduard van Valkenburg (eavanvalkenburg)]

/review

[github-actions]

MAF Automated Review — Iteration 1

Result: Findings reported
Scope: full PR (1 commit(s)): 722a17ac8261
Model: gpt-5.6-sol

Overview

The PR consistently uses one predicate for tool schema generation and decoding, while existing collection serialization continues to omit null auto-generated keys before connector dispatch. The focused tests cover dictionary, dataclass, constructor, supplied-key, and invalid-key paths. Residual risk remains because the predicate can choose a different annotation source than model definition parsing, and the schema change leaves an existing MongoDB connector test failing.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
2 verified findings remained after source verification (2 medium) across 1 file. Details are attached to the affected lines below.

Affected areas: python/packages/core/agent_framework/_vectors.py

[Eduard van Valkenburg (eavanvalkenburg)]

Sunhy (@Shy7777) The current-head Python 3.10 CI failure is caused by the new constructor-nullability coverage, not infrastructure: all four test_vector_upsert_tool_respects_constructor_key_nullability variants fail while building InMemoryCollection(record_type) because the decorated definition contains no key field (ValueError: A vector store definition must contain exactly one key field). The Windows and Python 3.15 jobs were then cancelled by fail-fast, and Merge Gatekeeper failed on that test result. Please make constructor Annotated[..., VectorStoreField("key")] discovery work on the supported Python 3.10 path and add/retain a regression that runs there before requesting another review.

[Jose Alvarez (jpalvarezl)]

Thank you for the contribution. This pull request has had an outstanding request to make constructor key-field discovery work on supported Python 3.10, with the related required tests still failing, for more than three days without recent progress. We are closing it for now to keep the review queue current. Please reopen it when you are ready to continue and address the outstanding item, and we will be happy to take another look.