EF doesn't throw exception and returns incorrect result when using only part of composite key

[JohnyL]

File a bug

Say, I have a simple table with two columns:

/* Create table */
CREATE TABLE dbo.logger
(
    [user_id]   int          not null,
    [timestamp] datetime2(0) not null
);

/* Create composite key */
ALTER TABLE dbo.logger
ADD CONSTRAINT PK_logger PRIMARY KEY ([user_id], [timestamp]);

/* Insert two rows */
INSERT INTO dbo.logger VALUES
(1, '2021-02-24 14:25:07'),
(1, '2021-02-24 14:34:41');

Next, setup database context:

public record LogEntry(int UserId, DateTime Timestamp);

public class LoggerContext : DbContext
{
    public DbSet<LogEntry> Logs { get; set; }
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<LogEntry>(builder =>
        {
            builder
                .ToTable("logger", schema: "dbo")
                .HasKey(p => p.UserId);
            builder
                .Property(p => p.UserId)
                .HasColumnName("user_id");
            builder
                .Property(p => p.Timestamp)
                .HasColumnName("timestamp");
        });
    }
}

Looks legit, but actually there's an error - the key is composite, so it must be .HasKey(p => new { p.UserId, p.Timestamp}). The thing is that I didn't notice this for the first time. So, I get the following results:

LogEntry { UserId = 1, Timestamp = 24.02.2021 14:25:07 }
LogEntry { UserId = 1, Timestamp = 24.02.2021 14:25:07 }

H-m-m... Same data and time. Let's take a look at generated SQL in profiler:

SELECT [l].[user_id], [l].[timestamp]
FROM [dbo].[logger] AS [l]

The generated SQL is as expected.

So, why EF didn't throw exception and let bogus data to return?

Include provider and version information

EF Core version: 6.0.0-preview.1.21102.2
Database provider: Microsoft.EntityFrameworkCore.SqlServer (SQL Server 2017 Microsoft SQL Server 2017 14.0.3381.3 x64)
Target framework: .NET 6.0.100-preview.1.21103.13
Operating system: Windows 10 Home x64 build 19042
IDE: Visual Studio 2019 16.9.0 Preview 5.0

[AndriySvyryd]

@JohnyL This is by-design. To avoid performing redundant checks EF assumes that the model matches the database. #831 should help to catch these types of mistakes.

[JohnyL]

If EF "assumes", then why dealing with exceptions? You could equally return bogus data in all cases where exceptions should be. I was figuring out the whole day this problem.