Don't transform Cosmos query to ReadItem when WithPartitionKey conflicts with predicate partition key

[Copilot]

Combining WithPartitionKey(...) with a predicate that also compares the partition key produced a ReadItem using the WithPartitionKey value, silently discarding the predicate. A conflicting value returned the WithPartitionKey document instead of zero results.

// Document exists at PK1 with Id == sharedId
context.Entities
    .WithPartitionKey("PK1")
    .Where(e => e.Id == sharedId && e.PartitionKey == "PK2")
    .SingleOrDefault();
// Before: ReadItem(["PK1"], sharedId) -> returns the PK1 document
// After:  regular query -> returns null (PK1 != PK2)

Changes

• CosmosReadItemAndPartitionKeysExtractor: skip the ReadItem transform only when partition key values supplied via WithPartitionKey() actually conflict with partition key comparisons in the predicate. Matching values remain eligible for ReadItem, while conflicting values execute as a regular query so the predicate is preserved and yields zero results.
• Fix repeated JSON id / partition-key comparison checks to compare expression values structurally, so equivalent repeated comparisons remain compatible with extraction and ReadItem eligibility.
• Conflict detection applies predicateValue.TypeMapping to the WithPartitionKey() value before comparing (since WithPartitionKey() arguments are translated with applyDefaultTypeMapping:false), ensuring identical constant/parameter pairs are correctly recognized as non-conflicting. A special case handles the SqlParameterExpression vs SqlConstantExpression mismatch that arises when a literal is passed to WithPartitionKey() (funcletized to a parameter) but written inline in the predicate (stays a constant): when all partition key properties are also part of the JSON ID, ReadItem is safe regardless.

Behavior change

• Queries that use both WithPartitionKey() and an equivalent predicate partition-key comparison (same values) continue to translate to ReadItem.
• Queries that use both WithPartitionKey() and conflicting predicate partition-key comparisons no longer translate to ReadItem; they execute as regular queries so the conflict is honored and no result is returned.
• Queries that use WithPartitionKey(pkVar) and PartitionKey == differentPkVar where both are different local variables holding the same runtime value cannot be recognized as equal at translate time and fall through to a full query (the result is still correct).

Tests

• Added WithPartitionKey_and_predicate_with_id_and_conflicting_partition_key (+ _leaf variant) covering the conflicting case (asserts empty).
• Added WithPartitionKey_and_predicate_with_id_two_locals_same_value documenting the behavior when WithPartitionKey and the predicate use two different local variables that happen to hold the same value — these cannot be recognized as equal at translate time, so the query falls through to a full SQL query (result is still correct).

[Copilot]

Pull request overview

This PR fixes an incorrect Cosmos optimization where a query could be transformed into a ReadItem call even when WithPartitionKey(...) conflicts with partition-key comparisons in the predicate—causing the predicate partition-key to be silently ignored and returning the wrong document. The change prevents the ReadItem transform in that scenario so the query executes normally and conflicting values correctly yield zero results.

Changes:

• Update CosmosReadItemAndPartitionKeysExtractor to skip the ReadItem transform when partition key values come from WithPartitionKey() and the predicate also contains partition key comparison(s).
• Add new functional tests for the conflicting WithPartitionKey + (id && partitionKey) predicate case (including leaf/inheritance variants).
• Update multiple Cosmos functional test SQL baselines to reflect the new (non-ReadItem) query shape in same-value scenarios.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/EFCore.Cosmos/Query/Internal/CosmosReadItemAndPartitionKeysExtractor.cs	Adds a predicate-partition-key-comparison flag and blocks ReadItem transform when WithPartitionKey() may conflict with predicate PK comparisons.
test/EFCore.Cosmos.FunctionalTests/Query/ReadItemPartitionKeyQueryTestBase.cs	Adds a new base test covering conflicting WithPartitionKey + predicate partition-key comparison.
test/EFCore.Cosmos.FunctionalTests/Query/ReadItemPartitionKeyQueryInheritanceTestBase.cs	Adds a leaf/inheritance variant of the conflicting-case test.
test/EFCore.Cosmos.FunctionalTests/Query/ReadItemPartitionKeyQueryTest.cs	Updates baselines to expect regular query SQL (not ReadItem) and adds baseline for the new conflicting-case test.
test/EFCore.Cosmos.FunctionalTests/Query/ReadItemPartitionKeyQueryRootDiscriminatorInIdTest.cs	Updates baselines for non-ReadItem query shape and adds baselines for the new conflicting-case tests.
test/EFCore.Cosmos.FunctionalTests/Query/ReadItemPartitionKeyQueryNoDiscriminatorInIdTest.cs	Updates baselines for non-ReadItem query shape and adds baselines for the new conflicting-case tests.
test/EFCore.Cosmos.FunctionalTests/Query/ReadItemPartitionKeyQueryDiscriminatorInIdTest.cs	Updates baselines for non-ReadItem query shape and adds baselines for the new conflicting-case tests.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

[AndriySvyryd]

@copilot Also add

    [Fact]
    public virtual Task WithPartitionKey_and_predicate_with_id_two_locals_same_value()
    {
        var pkForWith = "PK1";
        var pkForWhere = "PK1";

        return AssertQuery(
            async: true,
            ss => ss.Set<SinglePartitionKeyEntity>().WithPartitionKey(pkForWith)
                .Where(e => e.Id == Guid.Parse("B29BCED8-E1E5-420E-82D7-1C7A51703D34") && e.PartitionKey == pkForWhere),
            ss => ss.Set<SinglePartitionKeyEntity>().Where(e => e.PartitionKey == pkForWith)
                .Where(e => e.Id == Guid.Parse("B29BCED8-E1E5-420E-82D7-1C7A51703D34") && e.PartitionKey == pkForWhere));
    }

[Copilot]

Added in the latest commit. The test is in the base class and overridden in all four concrete test files with SQL baselines.

Since pkForWith and pkForWhere are two different local variables (even though both hold "PK1"), they produce two different SqlParameterExpressions at translate time (@pkForWith and @pkForWhere). The conflict check compares by expression equality (which uses parameter names), so they are not recognized as equal → ReadItem is skipped and the query runs as a full SQL query with @pkForWhere in the WHERE clause. The SQL baselines reflect this behavior.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.