Bump pretty much ALL packages for .NET 10#2264
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughCentral NuGet versioning file updates core version variables (MauiVersion to 10.0.60, HotChocolateVersion to 15.1.16) and refreshes the package version catalog with new explicit versions for Entity Framework, MongoDB, PostgreSQL, OpenTelemetry, Quartz, Polly, OpenIddict, and supporting libraries. The global Microsoft.VisualStudio.Threading.Analyzers reference is also bumped. ChangesNuGet Package and Version Updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Bumping linq2db.EntityFrameworkCore from 9.0.0 to 10.3.0 had more knock-on effects than I would like: it changed the baseline linq2db version from 5 to 6, and linq2db 6 included several breaking changes. But I suspect that dropping linq2db.EntityFrameworkCore back down to 9.0.0 would not work very well when we bump EF Core up to version 10. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@backend/Directory.Packages.props`:
- Around line 111-114: The PackageVersion entry for SQLitePCLRaw.lib.e_sqlite3
(Version="2.1.11") is incompatible with bundle_e_sqlite3 (3.0.3); replace that
PackageVersion with SourceGear.sqlite3 at 3.50.4.2 (or later) so the
bundle_e_sqlite3 / SQLitePCLRaw.config.e_sqlite3 dependency chain is satisfied,
or alternatively downgrade bundle_e_sqlite3 to the 2.x series to match
SQLitePCLRaw.lib.e_sqlite3—update the PackageVersion symbol accordingly (remove
or replace the SQLitePCLRaw.lib.e_sqlite3 entry and add/replace
SourceGear.sqlite3 with the newer version).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 3096712b-e0c2-43f6-a100-94c0c59bf5b8
📒 Files selected for processing (1)
backend/Directory.Packages.props
| <PackageVersion Include="SQLitePCLRaw.bundle_e_sqlite3" Version="3.0.3" /> | ||
| <PackageVersion Include="SQLitePCLRaw.core" Version="3.0.3" /> | ||
| <PackageVersion Include="SQLitePCLRaw.lib.e_sqlite3" Version="2.1.11" /> | ||
| <PackageVersion Include="SQLitePCLRaw.provider.e_sqlite3" Version="2.1.11" /> | ||
| <PackageVersion Include="Squidex.Assets.TusClient" Version="6.6.4" /> | ||
| <PackageVersion Include="SQLitePCLRaw.provider.e_sqlite3" Version="3.0.3" /> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest version of SQLitePCLRaw.lib.e_sqlite3 and is it compatible with SQLitePCLRaw 3.0.3?
💡 Result:
Latest SQLitePCLRaw.lib.e_sqlite3 version (as of 2026-05-12): 3.50.3.[1] Compatibility with SQLitePCLRaw 3.0.3: Not enough evidence found to confirm compatibility. SQLitePCLRaw 3.x uses different packaging: the recommended “crypto-enabled SQLite build” approach is to use SQLitePCLRaw.config.e_sqlite3 together with a native SQLite library package (e.g., SourceGear.sqlite3), and the native-library package name is no longer SQLitePCLRaw.lib.e_sqlite3 (it’s SourceGear.sqlite3 in SQLitePCLRaw 3.0+). [2][3] So, while SQLitePCLRaw.lib.e_sqlite3 exists at version 3.50.3, the sources indicate that in the SQLitePCLRaw 3.0+ line you should generally use SQLitePCLRaw.config.e_sqlite3 + SourceGear.sqlite3 instead of relying on SQLitePCLRaw.lib.e_sqlite3.[2][3]
Citations:
- 1: https://nuget.360scm.com/packages/sqlitepclraw.lib.e_sqlite3
- 2: https://github.com/ericsink/SQLitePCL.raw/
- 3: https://github.com/ericsink/SQLitePCL.raw/blob/main/v3.md
🏁 Script executed:
# Check the Directory.Packages.props file for SQLitePCLRaw packages and SQLite-related entries
grep -n -i "sqlite\|SourceGear" backend/Directory.Packages.propsRepository: sillsdev/languageforge-lexbox
Length of output: 483
🌐 Web query:
SQLitePCLRaw.bundle_e_sqlite3 3.0.3 lib.e_sqlite3 2.1.11 compatibility
💡 Result:
SQLitePCLRaw.bundle_e_sqlite3 version 3.0.3 (or latest 3.0.x like 3.0.2) is not compatible with SQLitePCLRaw.lib.e_sqlite3 version 2.1.11. In SQLitePCLRaw 3.0, the native library package changed from SQLitePCLRaw.lib.e_sqlite3 (2.x series) to SourceGear.sqlite3 (now using SQLite version numbers like 3.50+).[1][2] The bundle_e_sqlite3 3.0.x now depends on SQLitePCLRaw.config.e_sqlite3 (>=3.0.x) and SourceGear.sqlite3, not the old lib.e_sqlite3 2.1.11.[3][4][5] Using the old lib.e_sqlite3 2.1.11 with bundle 3.0.x would cause conflicts due to different native libraries and provider expectations.[6][1] Recommendation: Update to SourceGear.sqlite3 (e.g., 3.50.4.2 as used in examples) or use bundle_e_sqlite3 2.1.11 if needing the old lib.[7][8]
Citations:
- 1: https://github.com/ericsink/SQLitePCL.raw/blob/main/v3.md
- 2: https://github.com/ericsink/SQLitePCL.raw/wiki/Package-ID-change:-SQLitePCLRaw.lib.e_sqlite3-is-now-SourceGear.sqlite3
- 3: https://www.nuget.org/packages/sqlitepclraw.bundle_e_sqlite3/
- 4: https://libraries.io/nuget/SQLitePCLRaw.bundle_e_sqlite3
- 5: https://nuget.360scm.com/packages/sqlitepclraw.bundle_e_sqlite3/3.0.0
- 6: Update to SQLitePCLRaw 3.x dotnet/efcore#36535
- 7: Update to SQLitePCLRaw 3.0 praeclarum/sqlite-net#1282
- 8: https://github.com/ericsink/SQLitePCL.raw
Fix SQLitePCLRaw package incompatibility — lib.e_sqlite3 2.1.11 conflicts with bundle_e_sqlite3 3.0.3.
SQLitePCLRaw 3.0 changed native library handling from SQLitePCLRaw.lib.e_sqlite3 (2.x series) to SourceGear.sqlite3. The bundle_e_sqlite3 3.0.3 depends on SourceGear.sqlite3 and SQLitePCLRaw.config.e_sqlite3, not the old 2.1.11 lib package. This mismatch will cause runtime conflicts. Replace SQLitePCLRaw.lib.e_sqlite3 2.1.11 with SourceGear.sqlite3 3.50.4.2 or later, or downgrade the bundle to 2.1.11 if needed.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@backend/Directory.Packages.props` around lines 111 - 114, The PackageVersion
entry for SQLitePCLRaw.lib.e_sqlite3 (Version="2.1.11") is incompatible with
bundle_e_sqlite3 (3.0.3); replace that PackageVersion with SourceGear.sqlite3 at
3.50.4.2 (or later) so the bundle_e_sqlite3 / SQLitePCLRaw.config.e_sqlite3
dependency chain is satisfied, or alternatively downgrade bundle_e_sqlite3 to
the 2.x series to match SQLitePCLRaw.lib.e_sqlite3—update the PackageVersion
symbol accordingly (remove or replace the SQLitePCLRaw.lib.e_sqlite3 entry and
add/replace SourceGear.sqlite3 with the newer version).
|
@CodeRabbit - Several files, such as backend/FwLite/FwLiteWeb/Routes/ActivityRoutes.cs, are failing to compile with the error "The type or namespace name 'Models' does not exist in the namespace 'Microsoft.OpenApi' (are you missing an assembly reference?)". Please find out where the namespace name Models was moved to. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain
FixUpdate any In practice, replace: using Microsoft.OpenApi.Models;with: using Microsoft.OpenApi;Additional breaking changes in Microsoft.OpenApi 2.0 to be aware ofYou may hit further compile errors beyond the namespace rename. Entities within the OpenAPI document, like operations and parameters, are now typed as interfaces, with concrete implementations existing for inlined and referenced variants. For example, an
Important caution: don't accidentally pull in Microsoft.OpenApi 3.x.NET 10's OpenAPI generator was built against the 2.x OpenAPI model, so when version 3.x is present, the generator attempts to assign values to properties that are no longer writable — resulting in build failures. Make sure your 🏁 Script executed: Length of output: 363 🌐 Web query: 💡 Result: In newer OpenAPI.NET / ASP.NET Core OpenAPI stacks, the What changed (the breaking symptom)
What to do
Important nuance (common in .NET 10 migrations)
Sources: [1] [2] [3] Let me check the specific usages in the affected files to give you a more complete picture. 🏁 Script executed: Length of output: 2712
All 8 files — Simple fixReplace
|
github-actions
Bot
added
💻 FW Lite
|
@CodeRabbit rate limit |
|
Review rate limit: 0/1 reviews remaining, refill in 33 minutes and 18 seconds. |
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
|
@CodeRabbit - Next question. In backend/FwLite/FwLiteWeb/Routes/MiniLcmRoutes.cs, |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainLet me read the file and check the latest Microsoft.OpenApi 2.0 docs. I have the web search results. Let me also check the actual file content now that the script has run. The script is still executing. Let me provide my analysis based on what I know so far while waiting for the file content.
The root cause of the error is a breaking change in Microsoft.OpenApi 2.0, which ships with .NET 10. What changedIn .NET 10, entities within the OpenAPI document — like operations and parameters — are typed as interfaces. Concrete implementations exist for the inlined and referenced variants of an entity. Specifically, The
So code like: new OpenApiParameter { Name = "format", In = ParameterLocation.Query, ... }…now fails because The fixFor typical query, path, header, or cookie parameters, use one of the concrete non-abstract subclasses. From the OpenAPI.NET v2 upgrade guide, the mapping is:
For the common case of I'd need to see the actual code at those lines to give you the exact class names. The script I kicked off is retrieving the file content now — once those results come back, I can provide a concrete diff. Could you share the code at lines 36–56 of 🏁 Script executed: Length of output: 4796 🏁 Script executed: Length of output: 4796
Root CauseIn Microsoft.OpenApi 2.0, There's also a secondary error lurking on line 48: The FixReplace both // Lines 36-50: replace new() with new OpenApiParameter(), and fix Type
operation.Parameters?.Add(new OpenApiParameter()
{
Name = "projectType",
In = ParameterLocation.Path,
Required = true,
Schema = new OpenApiSchema()
{
Enum =
[
JsonValue.Create(ProjectDataFormat.FwData.ToString()),
JsonValue.Create(ProjectDataFormat.Harmony.ToString())
],
Type = JsonSchemaType.String // was: Type = "string"
},
});
// Lines 51-56: replace new() with new OpenApiParameter()
operation.Parameters?.Add(new OpenApiParameter()
{
Name = "projectCode",
In = ParameterLocation.Path,
Required = true
});
|
|
@CodeRabbit - Next question. backend/FwHeadless/Program.cs has an error on line 48: "'EntityFrameworkInstrumentationOptions' does not contain a definition for 'SetDbStatementForText' and no accessible extension method 'SetDbStatementForText' accepting a first argument of type 'EntityFrameworkInstrumentationOptions' could be found (are you missing a using directive or an assembly reference?)". Explain the error and suggest a fix. |
|
Good news: sillsdev/harmony#63 is finally green (after much re-running the build with no changes until a GHA runner was finally fast enough to satisfy the performance test), which would have blocked this PR from being merged. (Harmony needs to acquire a .net 10 build at the same time that FW Lite does). |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainLet me check the file and look up the breaking change. 🏁 Script executed: Unrecoverable error: Failed to clone repository 🌐 Web query: 💡 Result:
What to do now:
Sources:
Root Cause
The FixIt depends on what the code at line 48 is doing: Case 1 — You were enabling it ( Simply delete that line of code; it's now the default behavior. // Before
.AddEntityFrameworkCoreInstrumentation(o =>
{
o.SetDbStatementForText = true; // <-- delete this line
})
// After
.AddEntityFrameworkCoreInstrumentation()Case 2 — You were suppressing it ( There is no longer a built-in switch in the EFCore instrumentation options to suppress statement text. You'll need to drop/clear the statement attribute(s) in your pipeline via a custom A minimal suppression processor would look like: public class RedactDbStatementProcessor : BaseProcessor<Activity>
{
public override void OnEnd(Activity activity)
{
if (activity.GetTagItem("db.statement") != null)
activity.SetTag("db.statement", null);
}
}
// Register it:
.AddEntityFrameworkCoreInstrumentation()
// ...
.AddProcessor(new RedactDbStatementProcessor())Given this is a backend service ( |
|
@CodeRabbit - Next question. In backend/LexBoxApi/Services/DevGqlSchemaWriterService.cs, line 14 errors with "The type 'RequestExecutorProxy' exists in both 'HotChocolate.Execution.Abstractions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null' and 'HotChocolate.Execution, Version=15.1.16.0, Culture=neutral, PublicKeyToken=null'". The Directory.Packages.props file is requesting version 15.1.16.0 of the HotChocolate packages, so I don't know where the version 16 reference is coming from. Is it coming from a transitive NuGet dependency? If so, please identify the package that is referencing HotChocolate 16, and identify the latest version of that package that still references HotChocolate 15. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainThe scripts are running to gather the codebase context. Let me also search for which specific packages are known to pull in HotChocolate 16 transitively. I'm waiting for the script results. While the scripts are running, let me check if HC 16 is a pre-release being pulled in. I'm still waiting for the script results. Let me check if GreenDonut is the culprit:
Root CauseHotChocolate 16 is pre-release only (versions like The conflict happens because something in the build is pulling in Why is HC 16 being pulled in?The most likely cause is that one of the non- The prime suspects in a typical HotChocolate-heavy backend are:
How to diagnose definitivelyThe fastest way to find the culprit is: This will print the full dependency chain showing exactly which package is pulling in Alternatively, examine the generated The FixOnce you've identified the offending package (call it Option A — Pin HC 16 transitive packages in <!-- Force these transitively-pulled HC 16 packages back to 15.x -->
<PackageVersion Include="HotChocolate.Execution.Abstractions" Version="$(HotChocolateVersion)" />Option B — Downgrade Option A is usually faster to apply but may hide compatibility issues; Option B is cleaner long-term. 🏁 Script executed: Length of output: 4103 🏁 Script executed: Length of output: 71 🏁 Script executed: Length of output: 75 🏁 Script executed: Length of output: 11155 🌐 Web query: 💡 Result:
Citations: Now I can see the full picture. The key suspect is 🌐 Web query: 💡 Result:
Source: [1] Found it. Now let me find the latest version that still targets HC 15. 🌐 Web query: 💡 Result:
Root Cause
The FixDowngrade <!-- Before -->
<PackageVersion Include="DataAnnotatedModelValidations" Version="11.0.0" />
<!-- After -->
<PackageVersion Include="DataAnnotatedModelValidations" Version="10.0.0" />That single change should eliminate the |
|
@CodeRabbit - Next question. Line 61 of backend/LexBoxApi/GraphQL/CustomTypes/IsLanguageForgeProjectDataLoader.cs is erroring out with "The type arguments for method 'MongoExtensions.ToAsyncEnumerable(IMongoCollection)' cannot be inferred from the usage. Try specifying the type arguments explicitly." Suggest the type arguments needed for this line. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 19475
The FixExplicitly specify // Before (line 61)
var actualProjects = await MongoExtensions.ToAsyncEnumerable(loader._systemDbContext.Projects.AsQueryable()
.Select(p => p.ProjectCode)
`#pragma` warning disable MALinq2001
.Where(projectCode => list.Contains(projectCode)))
`#pragma` warning restore MALinq2001
.ToHashSetAsync(cancellationToken: token);
// After — add explicit <string> type argument
var actualProjects = await MongoExtensions.ToAsyncEnumerable<string>(loader._systemDbContext.Projects.AsQueryable()
.Select(p => p.ProjectCode)
`#pragma` warning disable MALinq2001
.Where(projectCode => list.Contains(projectCode)))
`#pragma` warning restore MALinq2001
.ToHashSetAsync(cancellationToken: token);This tells the compiler to use the |
|
@CodeRabbit - Next question. Line 94 of backend/FwLite/LcmCrdt.Tests/EntityCopyMethodTests.cs is erroring out with "'INode' does not contain a definition for 'Description' and no accessible extension method 'Description' accepting a first argument of type 'INode' could be found (are you missing a using directive or an assembly reference?)". Identify the cause and suggest a fix. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 2507 |
When I do that, the whole LINQ expression fails to compile with the error "Argument 1: cannot convert from 'System.Linq.IQueryable' to 'MongoDB.Driver.IMongoCollection'". |
|
@CodeRabbit - Next question. Please read #2264 (comment) and suggest a fix for the "cannot convert from 'System.Linq.IQueryable' to 'MongoDB.Driver.IMongoCollection'" error. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 16684
Root Cause
The problem is that in the newer MongoDB.Driver (3.x), chaining The FixAvoid LINQ projection entirely and use the MongoDB Fluent API ( private static async Task<Dictionary<string, bool>> LoadBatch(IsLanguageForgeProjectDataLoader loader,
IReadOnlyList<string> list,
CancellationToken token)
{
var actualProjects = (await loader._systemDbContext.Projects
.Find(Builders<Project>.Filter.In(p => p.ProjectCode, list))
.Project(p => p.ProjectCode)
.ToListAsync(token))
.ToHashSet();
return list.ToDictionary(pc => pc, pc => actualProjects.Contains(pc));
}This removes the LINQ chain entirely, eliminates the You'll need to ensure |
|
@CodeRabbit - Next question. backend/FwLite/LcmCrdt.Tests/EntityCopyMethodTests.cs fails to build. |
|
Tip For best results, initiate chat on the files or code changes.
Root CauseThe project is on FluentAssertions 8.9.0, which introduced a breaking change to the equivalency API in v8.0.0. In FA 7.x, The FixReplace // Before (line 94)
.FailWith("Subject and Expectation for {0} should not reference the same instance in memory.", context.CurrentNode.Description);
// After
.FailWith("Subject and Expectation for {0} should not reference the same instance in memory.", context.CurrentNode.Subject.Description);
|
|
@CodeRabbit - Next question. backend/Testing/SyncReverseProxy/LegacyProjectApiTests.cs has two lines, 105 and 121, which fail to compile. Both are the same: |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🌐 Web query: 💡 Result: In FluentAssertions v8.7.0 the new System.Text.Json Migration: JsonNode node = JsonNode.Parse(@"{ ""name"": ""John"" }");
// old idea (dictionary-style): ContainKey("name") // not available on JsonNodeAssertions
node.Should().HaveProperty("name");
node.Should().NotHaveProperty("code");If you truly want dictionary assertions, you’d need to assert on a dictionary-like view/type (since Sources 🏁 Script executed: Length of output: 2625
Root CauseIn FA 8.7.0, a new dedicated The FixReplace // Before (lines 105 and 121)
responseObject.Should().ContainKey("error");
// After
responseObject.Should().HaveProperty("error");No The rest of the assertion chain ( |
The .NET 10 / Linq2Db v6 fixes turned many fast-failing tests into slow-passing tests (they now actually run to completion). On Windows CI the LcmCrdt + FwLiteProjectSync test step needs more than 40 min.
Adds LINQ2DB-V6-NOTES.md next to the affected code with: the two v6 behavior changes that triggered the issues, the matrix of workarounds we tried, the trade-off the current code picks, links to the migration wiki / related issues / in-flight PR, and a clear revert checklist for when upstream lands a fix. Drops TODO pointers to that doc in the two source locations holding the workaround (Json.QueryInternal bodies and the SemanticDomains / PublishIn ExpressionMethodAttribute expressions in LcmCrdtKernel).
linq2db v6 introduced regressions around [ExpressionMethod] materialization that this branch had been working around with growing hacks (.ToList wraps, raw-SQL test inserts, JSON path-builder Alias unwrap, etc.) — see backup branch wip/linq2db-v6-attempts and tag pre-linq2db-downgrade for the in-progress work. Decouple linq2db from .NET 10: keep the framework + ASP.NET / EF.Sqlite on 10.x, but pin linq2db.AspNet 5.4.1 (renamed from .Extensions in v6) linq2db.EntityFrameworkCore 9.0.0 Microsoft.EntityFrameworkCore* 9.0.16 Npgsql / .EntityFrameworkCore.PostgreSQL 9.0.5 / 9.0.4 Gridify(.EntityFramework) 2.17.0 (last without explicit net10.0 TFM) NeinLinq(.EntityFrameworkCore) 7.3.2 OpenIddict.* 7.1.0 (same — net10 TFM forces EF 10) The downgrade is mirrored in the harmony submodule (chore/linq2db-v5-on-net10). Files that picked up v6-only API surface (LinqToDB.Internal.*, .Extensions.Logging, UseSQLiteMicrosoft, SqlExpression(new DbDataType ...), etc.) are restored to develop's v5-shaped form. The v6 docs (LINQ2DB-V6-NOTES.md) and regression-test file are removed; both live on the backup branch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After the linq2db v5 / EF Core 9 pin, several earlier branch fixes were either no-op churn or workarounds for problems that no longer apply. Clean them up so the diff vs develop reflects what's actually changing: - CI: drop the fw-lite job's 40→60 timeout bump. The "tests run to completion now instead of fast-failing" justification was a v6 perf hit; gone with the downgrade. - FwHeadless: restore `c.SetDbStatementForText = true`. The line was dropped because OpenTelemetry.Instrumentation.EntityFrameworkCore 1.13+ removed the property (now always-on). Pin to 1.12.0-beta.2 so the explicit opt-in stays in source. - SystemTextJsonPatch: pin to 3.3.0 and revert the JsonElement-aware RichMultiString.IDictionary.Add. v5's PocoAdapter change forced the workaround; 3.x doesn't. - EmailService: drop the `if (admin.Email is not null)` skip-on-null guard. An admin without an email is a programming error — fail loudly. MailKit 4.16's tightened nullability means we need an explicit throw rather than the bare ctor call develop has. - EF snapshots and the Quartz migration: regenerated on EF Core 9 (dotnet-ef tool pinned to 9.0.16). Removes the EF10 syntactic noise (DiscriminatorProperty drop, ToTable null cast, ComplexProperty signature change, lost Optional/Required annotations on nav props, ProductVersion bump) so the snapshot diff is exactly the two real schema changes the migration applies: Quartz misfire_orig_fire_time and OpenIddictTokens.Type widened 50→150. - LexData: revert no-op linq2db/AspNet using/PackageReference re-order back to develop's order. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
OpenTelemetry.Instrumentation.EntityFrameworkCore: back to 1.15.1-beta.1. SetDbStatementForText was the default starting 1.13, so the line that explicitly set it true is now redundant — drop it; behaviour preserved. SystemTextJsonPatch: back to 5.0.0. The reason the v5 bump needed the JsonElement workaround on RichMultiString.IDictionary.Add is that STJP's PocoAdapter routes non-generic-IDictionary targets through DictionaryPropertyProxy, whose PropertyType returns typeof(object) for keys that don't exist yet — so ConversionResultProvider.TryConvertTo doesn't deserialize, and our explicit IDictionary.Add receives the raw JsonElement. Cleaner fix: make RichMultiString implement IDictionary<WritingSystemId, RichString>. STJP then picks DictionaryTypedPropertyProxy<,> instead, which knows the value type and deserialises to RichString before assigning. Our IDictionary.Add(object, object) reverts to the simple `value as RichString ?? throw` cast — same as develop — because the JsonElement case no longer reaches it. Only addition needed for the new interface was CopyTo(KeyValuePair<,>[], int); everything else (Add, Remove, indexer, ContainsKey, TryGetValue, Keys, Values, Count, IsReadOnly) was already present. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The IDictionary<,> implementation on RichMultiString alone wasn't enough to route through DictionaryTypedPropertyProxy<,>: STJP also requires the key type's TypeConverter to support string conversion. Without it, STJP falls back to the non-generic DictionaryPropertyProxy, whose PropertyType returns typeof(object) for new keys — meaning no deserialization happens and our explicit IDictionary.Add gets a raw JsonElement. Add a TypeConverter that does string ↔ WritingSystemId via the existing Parse method (and ToString back). WritingSystemId already has implicit string conversion at the C# level, ISpanParsable<T>, and a JsonConverter — making it TypeDescriptor-visible too is the missing piece and the right shape for ASP.NET route/config binders as well. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The model snapshot was restored from develop (which captured EF 9.0.6). We're running 9.0.16 now, so the VerifyDbModel test was comparing a "9.0.16" model against a "9.0.6" verified file and failing on that one line. Patch the version in both the migration snapshot and the verified file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
STJP's DictionaryTypedPropertyProxy casts to IDictionary<TKey, TValue?> and passes null when an "add /xxx" patch value deserialises to a null RichString (e.g. for an empty-string write that the converter folds to null). The non-generic indexer already handled that by removing the key; the typed one was calling value.EnsureWs(key) on null and throwing NRE. Mirror the same remove-on-null behaviour. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The recent attempt to revert to 40 was based on the assumption that the slowdown was specific to linq2db v6, but the latest CI run (linq2db v5 + EF Core 9 + .NET 10) confirms the test step still exceeds 40 minutes — the slowdown is from .NET 10 itself (some tests that used to fast-fail now run to completion). Document that and restore 60 until we investigate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Dotnet test step on this branch hangs (>40 min) where develop finishes in ~15 min. xUnit's default progress only prints failures and skips, so we have no visibility into which test is stuck after the last reported event. - `--blame-hang-timeout 5m` causes the runner to capture a dump if any single test runs longer than 5 minutes, identifying the culprit. - `--blame-hang-dump-type full` gets a full process dump for postmortem. - `console;verbosity=normal` adds per-test "Passed" lines so we can see exactly when (and where) the run stalls. This is a temporary diagnostic step; revert once the slowdown is found. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The CI --blame-hang dump fingered LcmCrdt.Tests.SnapshotAtCommitServiceTests. PreserveAllFieldWorksCommits_IncludesFieldWorksChangesInSnapshot as the stuck test. That test exercises SQLite's BackupDatabase API to fork a shared-cache in-memory DB. Locally it finishes in 14s, but on the windows-latest CI runner it idles for >5 minutes — symptomatic of a lock/IO wait in the bundled SQLite library. SQLitePCLRaw 3.0 bumped the bundled SQLite version, which is the most plausible Windows-only behaviour change between develop (2.1.11, test finishes) and this branch (3.0.3, test hangs). Keeping --blame-hang-timeout / --blame-hang-dump-type / console verbose for one more run to confirm the test passes after the downgrade and to catch any remaining slow tests. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Neither downgrade fixed the hang on PreserveAllFieldWorksCommits, so reset those packages. Bump blame-hang-timeout 5m -> 15m: maybe the test is genuinely just slow rather than deadlocked (develop ran the whole class in 14m36s on the same Windows runner). Diagnostic flags stay on so we can confirm pass-vs-hang. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The --blame-hang dump from the windows-latest CI runner showed
SnapshotAtCommitServiceTests.PreserveAllFieldWorksCommits_Includes…
stuck in FluentAssertions:
snapshotDefault.Should().NotBeEquivalentTo(snapshotPreserved)
→ LooselyOrderedEquivalencyStrategy<Guid>.FindClosestMismatches
→ AssertionChain.FailWith → Regex.Replace
→ (recursive, ~depth 20+ from the parallel-stack output)
FA 8.x's loose-ordering deep equivalency check is exponential in the
size of nested collections. Snapshots include the 30+ predefined morph
types plus writing systems / parts-of-speech / publications, so the
NotBeEquivalentTo blew up to >5 minutes on Windows CI (develop, on FA
7.0.0-alpha.5, ran the same test as part of the 14m36s LcmCrdt.Tests
batch with no hang). Locally on this branch the same test took 14s on
FA 8 and now 5s on FA 7 — so going back to develop's 7.0.0-alpha.5
makes the symptom disappear cleanly.
Revert the three "FluentAssertions breaking change" commits' source
edits since FA 7 doesn't need them — except where they actually fixed
FluentValidation 12 (ShouldHaveAnyValidationError → ShouldHaveValidationErrors)
or Squidex.Assets-TusClient using/namespace splits, both of which stay.
Also restore the fw-lite job to timeout-minutes: 40 and drop the
--blame-hang / dump-upload diagnostics that were added to find this.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MAUI 10's MSIX packaging targets no longer honour --artifacts-path; they write AppPackages relative to the FwLiteMaui project directory instead of under artifacts/bin/. The cp glob was still pointing at the old artifacts/bin/.../AppPackages path, so MakeAppx received an empty directory and failed with "bundle must contain at least one app package targeting a known processor architecture". Source from AppPackages/*/*.msix (relative to the working-directory, which is backend/FwLite/FwLiteMaui). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Setting -p:AppxPackageDir=../artifacts/AppPackages/ is the MSIX-targets equivalent of --artifacts-path; without it MAUI 10 writes AppPackages to the project directory regardless of --artifacts-path. With both set everything lives under a single artifacts/ tree which: - matches the layout we had pre-bump (msix output reachable under artifacts/...) - removes the implicit "but what if Debug" hypothetical from the cp glob by forcing the output to a single known location we control - doesn't change any signed/zipped/uploaded artifact (the msixbundle is built from the same .msix contents and uploaded as a single file) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The DataLoader's constructor used [Service(ResiliencePolicyName)] to inject the typed Polly pipeline, but that attribute is Hot Chocolate's resolver- pipeline marker — ActivatorUtilities (which constructs DataLoaders) doesn't honour it. The bare ResiliencePipeline<T> lookup then failed because AddResiliencePipeline<string, T> only registers a ResiliencePipelineProvider <string>, not a keyed pipeline. This path was never test-covered, so the bug had been silently present on develop too — the LF-project detection always threw at construction time. Surfaced today by querying isLanguageForgeProject on the deployed branch. Inject the provider and resolve the pipeline by name in the constructor — the canonical Polly 8.x pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
myieye
force-pushed
the
chore/update-nuget-pkgs-dotnet-10
branch
from
db4a2ca to
02ab435
Compare
linq2db.AspNet+linq2db.EntityFrameworkCore 9.0.0 (v5 API) → linq2db.Extensions 6.2.1 + linq2db.EntityFrameworkCore 10.3.0 (v6 API). EF Core 9.0.x → 10.0.7, Npgsql 9→10, NeinLinq 7.3→7.4, OpenIddict 7.1→7.5, Gridify 2.17→2.19. Robin's PR #2264 handled everything else in the .NET 10 bump; this PR covers only the linq2db/EF Core upgrade and its specific workarounds. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Advances from 50b0e2da (Robin's PR #2264 base) to 96a75b26 which adds the HasCommit TOCTOU fix: the commit-presence check now happens inside the lock in DataModel.Add, preventing a race where two concurrent callers could both pass the check and then collide on insert. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 participants
Fixes most of #2263.
Follow up PR will do:
This PR also happened to fix the
IsLanguageForgeProjectGQL loader which was/is currently broken in all environments.