Fix/7577 Fix ElsaContext Auto Migrations EfCore9 + MSSQL + Custom Elsa db schema (PendingModelChanges error)#7578
Fix/7577 Fix ElsaContext Auto Migrations EfCore9 + MSSQL + Custom Elsa db schema (PendingModelChanges error)#7578fgollas wants to merge 11 commits into
Conversation
Use Enumerate(TemplateContext) instead of Enumerate() (which is obsolete and returns an empty array)
…ttribute (elsa-workflows#6631) * fix: versioning nuget package changed from deprecated one to asp versioning for elsa server api * fix: iformfile attributes removed from workflowdefinitions endpoint --------- Co-authored-by: Selin Koykiran <selin.koykiran@siemens.com>
* Added .Net10 support * deleted icon --------- Co-authored-by: Beka Kvariani <bkvariani@tbcbank.com.ge>
…flows#7377) - Bump project version to 2.16. - Add Swashbuckle.AspNetCore packages for .NET 10.0 builds. - Refactor XEnumNamesSchemaFilter with conditional logic for .NET 10.0+ using new OpenAPI APIs. - Update ServiceCollectionExtensions to use new schema types and mappings for .NET 10.0+. - Preserve compatibility with earlier .NET versions.
…ws#7363) * fix(eslint): remove eslint from productiv dependencies ESlint should be used as dev dependency only. * chore(eslint): align version of eslint
…a custom schema for ElsaContext. In EFCore9 Microsoft validates Migrations snapshot schema ('Elsa') against the deployed schema (custom, like 'MyElsa') and throws with RelationalEventId.PendingModelChangesWarning event if those schemas differ.
|
PR author is not in the allowed authors list. |
|
@fgollas please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by .NET Foundation and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. |
|
@dotnet-policy-service agree company="MMI" |
|
Thanks for taking the time to put this together. I agree with the problem described in #7577, but this PR is too broad for us to review and merge safely as a bug fix. Besides the EF Core / SQL Server custom-schema migration behavior, it also changes target frameworks, package versions, API versioning/OpenAPI code, publishing configuration, and package lock files across unrelated areas. Could you please narrow this PR to only the The ideal shape would be:
Once the PR is scoped to that single issue, it should be much easier to review. |
Purpose
The PR is intended to fix Startup issue with Auto Migrations for EFCore9 with MSSQL and a custom schema for ElsaContext: #7577
When using a custom schema for ElsaContext, consumers should no more see EFCore's PendingModelChanges event which (if unhandled) can lead to an unhandled exception in Elsa's MigrationRunner causing the application to crash on startup.
Targeting Elsa 2.16.1
Scope
Select one primary concern:
Description
Problem
See #7577
Solution
If a custom elsa schema is potentially set by the consumer, a custom IMigrationsModelDiffer is applied to EFCore which detects a custom schema and suppresses the current PendingModelChanges event.
Verification
Steps:
Hint: Alternatively you can checkout the sample app used to reproduce the issue, upgrade to the patched elsa version and run it to verify it starts properly: https://github.com/fgollas/elsa-bugreport-pendingmodelchanges-2.1.16/tree/main
Expected outcome:
Startup should succeed, especially no Crash or error related to PendingModelChangesWarning should be visible in the output.
Screenshots / Recordings (if applicable)
N/A
Commit Convention
We recommend using conventional commit prefixes:
fix:– Bug fixes (behavior change)feat:– New featuresrefactor:– Code changes without behavior changedocs:– Documentation updateschore:– Maintenance, tooling, or dependency updatestest:– Test additions or modificationsClear commit messages make reviews easier and history more meaningful.
Checklist