fix(deps): move the PgSql and MsSql EF providers onto the EF Core 8 line - #129
Merged
Conversation
The 8.0.1 image CrashLoopBackOffs at startup: System.TypeLoadException: Could not load type 'Microsoft.EntityFrameworkCore.Storage.IRelationalValueBufferFactoryFactory' from assembly 'Microsoft.EntityFrameworkCore.Relational, Version=8.0.24.0' That type was removed in EF Core 7. The projects moved to net8.0 in d48988f (2026-02-12) and most of the EF stack came with them — Design 8.0.24, Pomelo 8.0.3, EFCore.NamingConventions 8.0.3 — but two providers were left on the EF Core 5 line and call into an API that no longer exists: SW.Mtm.PgSql Npgsql.EntityFrameworkCore.PostgreSQL 5.0.10 -> 8.0.11 SW.Mtm.MsSql Microsoft.EntityFrameworkCore.SqlServer 5.0.11 -> 8.0.24 SqlServer is pinned to 8.0.24 so it matches the already-pinned Microsoft.EntityFrameworkCore.Design and keeps Relational on one patch level. Npgsql 8.0.11 is the newest 8.0.x. This blocked every deployment, not just playground: all six live releases (funride, kwickbox, tamweelna x staging/production) run dbType=PgSql. They are unaffected today only because they still run the 6.0.8 image, which predates the net8.0 migration. NOT taking Dependabot #110 (Npgsql -> 9.0.4) or #111 (Pomelo -> 9.0.0): both are EF Core 9 against an EF Core 8 app, the same major-version mismatch as #117/#118. Verified against a real PostgreSQL 16 container, same env for both images: ghcr.io/simplify9/mtm:8.0.1 -> TypeLoadException, process dies this build -> migrations run, 9 tables created in the mtm schema incl. _ef_migrations_history, app serves HTTP, zero errors in the log Unit tests pass (1/1) under the dotnet/sdk:8.0 image. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VHkpqv6dB6wjALyFe9ocMU
|
Warning Review limit reachedNext included review available in 27 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Repository: simplify9/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
MusaMisto
added a commit
that referenced
this pull request
Sep 1, 2026
…ain (#131) Production login returns HTTP 500: InvalidCastException: Reading as 'IEnumerable<ProfileDataItem>' is not supported for fields having DataTypeName 'jsonb' ---> NotSupportedException: Type 'IEnumerable`1' required dynamic JSON serialization, which requires an explicit opt-in; call 'EnableDynamicJson' Regression from #129, which moved Npgsql 5.0.10 -> 8.0.11 to fix the EF Core TypeLoadException. Npgsql 8 removed the implicit dynamic JSON serializer: mapping an arbitrary POCO collection to a json/jsonb column now requires EnableDynamicJson() on the data source. Three properties rely on it via StoreAsJson() — Tenant.ProfileData, TenantMembership.ProfileData and Account.ProfileData — and account.profile_data is jsonb in production. The blast radius is wider than login: UseApiKeyAsRequestContext materialises Account on every apikey-authenticated request, so ANY such request 500s. Startup.cs now builds a single NpgsqlDataSource with EnableDynamicJson() and hands it to UseNpgsql. It is built once outside the AddDbContext lambda — NpgsqlDataSource owns the connection pool, so constructing one per DbContext instance would leak pools. Verified A/B against the REAL production database, same request, same data: ghcr.io/simplify9/mtm:8.0.3 GET /api/accounts -> 500 (8 exceptions) POST .../login -> 500 this build GET /api/accounts -> 200 (0 exceptions, real account data) POST .../login -> 400 (handler reached, bad password rejected) No schema changes were applied during the test — the 2021 migrations are already present, so startup migration is a no-op. Claude-Session: https://claude.ai/code/session_01VHkpqv6dB6wjALyFe9ocMU Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Root cause
The
8.0.1image CrashLoopBackOffs at startup, inMigrateDatabase:That type was removed in EF Core 7. The projects moved to
net8.0ind48988f(2026-02-12) and most of the EF stack came along —Design 8.0.24,Pomelo 8.0.3,EFCore.NamingConventions 8.0.3— but two providers were left on the EF Core 5 line, calling an API that no longer exists.SW.Mtm.PgSqlNpgsql.EntityFrameworkCore.PostgreSQL5.0.108.0.11SW.Mtm.MsSqlMicrosoft.EntityFrameworkCore.SqlServer5.0.118.0.24SqlServeris pinned to8.0.24so it matches the already-pinnedMicrosoft.EntityFrameworkCore.Designand keepsRelationalon a single patch level.Npgsql 8.0.11is the newest8.0.x.Blast radius
This blocked every deployment, not just playground — all six live releases (funride, kwickbox, tamweelna × staging/production) run
dbType: PgSql. They are unaffected today only because they still run the6.0.8image, which predates the net8.0 migration.#110proposes Npgsql → 9.0.4 and#111Pomelo → 9.0.0. Both are EF Core 9 against an EF Core 8 app — the same major-version mismatch as#117/#118(.NET 9). They should be closed, or the whole EF stack moved to 9 together.Verification — A/B against a real PostgreSQL 16, identical environment
ghcr.io/simplify9/mtm:8.0.1(deployed today)TypeLoadException, process diesThe fixed image did real database work, not just "didn't crash":
mtmschema, including_ef_migrations_history,account,tenant,refresh_token,otp_token…Unit tests pass (1/1) under
mcr.microsoft.com/dotnet/sdk:8.0.After merge
CI publishes
8.0.2. That is the first version that both routes through Gateway API and actually boots — the one downstream callers (includingfunride-mtm) should pin.🤖 Generated with Claude Code
https://claude.ai/code/session_01VHkpqv6dB6wjALyFe9ocMU