Regression: ExecuteUpdate fails for constant/literals assigned to for nullable int properties

[knopa]

After upgrading from EF Core 9 to EF Core 10, ExecuteUpdateAsync throws a System.InvalidOperationException when using SetProperty to assign a constant or captured value to a nullable property (int?).

I'm aware of the [breaking change in EF Core 10](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/breaking-changes#execute-update-expression) where the column setters parameter moved from Expression<Func<...>> to Func<...>. However, the nullable value-type coercion failure seems like it may be an unintended side effect of that change rather than expected behavior.

Exception

System.InvalidOperationException: No coercion operator is defined between types
'System.Func`2[MyApp.Models.MyEntity,System.Nullable`1[System.Int32]]' and 'System.Int32'.

Reproduce

Entity

public class Order
{
    public int Id { get; set; }
    public int? UpdatedById { get; set; }
    public string Status { get; set; }
}

Failing code (worked in EF Core 9)

const int SystemUserId = 1;

await dbContext.Orders
    .Where(x => ids.Contains(x.Id))
    .ExecuteUpdateAsync(s =>
    {
        s.SetProperty(p => p.UpdatedById, _ => SystemUserId);  // 💥 throws
        s.SetProperty(p => p.Status, _ => "Expired");
    });

The same pattern with non-nullable properties or string properties does not fail.

Workaround 1 — use entity parameter instead of discard

s.SetProperty(p => p.UpdatedById, p => (int?)SystemUserId);

Workaround 2 — capture as a pre-typed variable

int? systemUserId = SystemUserId;

await dbContext.Orders
    .Where(x => ids.Contains(x.Id))
    .ExecuteUpdateAsync(s =>
    {
        s.SetProperty(p => p.UpdatedById, p => systemUserId);
        s.SetProperty(p => p.Status, _ => "Expired");
    });

Expected behavior

Assigning a constant int value to an int? property via SetProperty should work regardless of whether the lambda uses a discard (_ =>) or an entity parameter (p =>). The implicit int → int? coercion should be handled transparently, as it was in EF Core 9.

Actual behavior

EF Core 10 throws InvalidOperationException at query compilation time. The error originates in TryTranslateSetterValueSelector, suggesting the new Func-based setter pipeline does not handle the int → Nullable<int> coercion when the lambda uses a discarded parameter.

Notably:

• Switching from _ => to p => resolves the issue, even though the parameter is unused.
• Pre-casting the value to int? outside the lambda also resolves it.
• Non-nullable value types and reference types (string) are unaffected.

This suggests the regression is specific to how the discard-parameter lambda's return type is inferred for nullable value types under the new Func-based API.

Stack trace

at System.Linq.Expressions.Expression.GetUserDefinedCoercionOrThrow(ExpressionType coercionType, Expression expression, Type convertToType)
at Microsoft.EntityFrameworkCore.Query.RelationalQueryableMethodTranslatingExpressionVisitor
    .<>c__DisplayClass108_0.<TryTranslateSetters>g__TryTranslateSetterValueSelector|6(...)
at Microsoft.EntityFrameworkCore.Query.RelationalQueryableMethodTranslatingExpressionVisitor
    .<>c__DisplayClass108_0.<TryTranslateScalarSetterValueSelector|5(...)
at Microsoft.EntityFrameworkCore.Query.RelationalQueryableMethodTranslatingExpressionVisitor
    .TryTranslateSetters(...)
at Microsoft.EntityFrameworkCore.SqlServer.Query.Internal
    .SqlServerQueryableMethodTranslatingExpressionVisitor.TryTranslateSetters(...)
at Microsoft.EntityFrameworkCore.Query.RelationalQueryableMethodTranslatingExpressionVisitor
    .TranslateExecuteUpdate(...)

Question

Is the nullable coercion failure with _ => an intended consequence of the Expression<Func<...>> → Func<...> migration, or is this a regression that should be handled by the new setter translation pipeline?

Provider and version information

• EF Core version: 10.0.0
• Database provider: Microsoft.EntityFrameworkCore.SqlServer
• Target framework: .NET 10
• Operating system: Linux (Docker)
• IDE: Visual Studio / Rider

[roji]

AI Triage

The below is an AI-generated analysis and may contain inaccuracies.

Classification

Bug — confirmed regression from EF Core 9 to EF Core 10. The bug also exists on the current main branch (11.0 development).

Root cause

The bug is in ExpressionTreeFuncletizer.VisitLambda (src/EFCore/Query/Internal/ExpressionTreeFuncletizer.cs).

When the value selector lambda body is a constant expression (e.g. _ => 1 for an int? property), the following happens:

1. VisitLambda visits the body and finds it evaluatable (EvaluatableWithoutCapturedVariable).
2. Since the lambda parameter is not in _evaluatableParameters, it calls ProcessEvaluatableRoot(lambda.Body, ref _state) to evaluate just the body.
3. Inside ProcessEvaluatableRoot, the body Convert(Constant(1, int), int?) is evaluated as a constant (not a parameter, because _inLambda is true and there's no captured variable). The evaluated result (int?)1 boxes to int, so a Constant(1, int) is created, and ConvertIfNeeded is called to wrap it back to int?.
4. ConvertIfNeeded calls Visit(Convert(Constant(1, int), int?)), which sets _state to EvaluatableWithoutCapturedVariable — corrupting the state that ProcessEvaluatableRoot had previously set to NoEvaluatability (since state is ref _state).
5. VisitLambda returns with _state = EvaluatableWithoutCapturedVariable, causing the parent VisitNew to treat the lambda as evaluatable.
6. The parent's EvaluateChildren → EvaluateList calls ProcessEvaluatableRoot on the entire lambda, compiling it to a Func<Order, int?> delegate and replacing it with a QueryParameterExpression of type Func<Order, int?>.
7. Later, TranslateSetterValueSelector receives this QueryParameterExpression instead of a LambdaExpression, fails the is LambdaExpression check, and tries Expression.Convert(Func<Order,int?>, int) which throws.

Why captured variables work: When the lambda body references a captured variable (_ => myVar), ProcessEvaluatableRoot takes the parameterize path (not constantize), which does not call ConvertIfNeeded and correctly leaves _state = NoEvaluatability.

Fix: After ProcessEvaluatableRoot at line 839 in VisitLambda, _state should be reset to NoEvaluatability, since we've already evaluated the body and the lambda itself must not be evaluatable (its parameters aren't evaluatable).

Reproduction

The issue reproduces with EF Core 10.0.5 (NuGet) and on the current main branch, on any database provider. It does not reproduce on EF Core 9.

Specifically affects SetProperty value selector lambdas whose body is a compile-time constant (const, literal) of a value type that needs implicit conversion to a nullable property type (e.g. int → int?).

Minimal repro

using System;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Logging;

await using var context = new TestContext();
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();

const int SystemUserId = 1;
var ids = new[] { 1, 2 };

await context.Orders
    .Where(x => ids.Contains(x.Id))
    .ExecuteUpdateAsync(s =>
    {
        s.SetProperty(p => p.UpdatedById, _ => SystemUserId);
    });

Console.WriteLine("ExecuteUpdate succeeded.");

public class Order
{
    public int Id { get; set; }
    public int? UpdatedById { get; set; }
    public string Status { get; set; } = "";
}

public class TestContext : DbContext
{
    public DbSet<Order> Orders { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseSqlite("Data Source=test.db")
            .LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging();
}

Possible duplicates

• ExecuteUpdate on Nullable stop working after migration from 8 to 9 #35164 — Same symptom (nullable coercion in SetProperty) reported for EF 8→9. Closed as duplicate of [Regression] Unexpected unbound variable error with closure #35152, which was a different funcletizer bug fixed in 9.0.1 (PR Correct VisitUnary operand evaluation in funcletizer #35172). The current issue is a different root cause reintroduced by the EF Core 10 ExecuteUpdate refactoring (the Action<UpdateSettersBuilder> change), which causes the funcletizer to encounter lambda expressions in a NewExpression context where the state corruption manifests.

[roji]

@knopa thanks for reporting, confirmed this is a bug and will fix for 11.0. As it is a bit of an edge case (constant/literal being assigned to a nullable value type property), for now am fixing this for 11.0; if other people run into this, we can consider backporting the fix for 10.0 at some point.