Repository navigation
chore(deps): drop the MessagePack pin that Aspire 13.6.3 makes redundant - #1356
Merged
Merged
Conversation
Aspire.Hosting 13.6.3 and its JavaScript, PostgreSQL, Redis, AppHost and Testing packages each require MessagePack 2.5.307 or later, so both AppHost locks still resolve 2.5.307 without the pin. Remove the central version, the AppHost reference and their comments, and regenerate the two AppHost locks. Update the MCP comments to the versions the API now resolves (SDK 2.3.0, Microsoft.Extensions.AI 10.11.0). The behaviour each comment cites is unchanged at those versions. Describe the verify probe, still on 2.2.0, as an older-client check.
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
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.
I pinned MessagePack in the AppHost to patch GHSA-qhrr-8q5h-9q3h (NU1902), because Aspire.Hosting and StreamJsonRpc brought in the vulnerable 2.5.302 as a transitive package. Since #1350 moved Aspire to 13.6.3, Aspire requires 2.5.307 itself, so the pin no longer raises anything. This PR removes the pin and brings the MCP comments up to the SDK versions the API now uses.
What changed
Directory.Packages.propsno longer has theMessagePackversion, andsrc/Cluckwork.AppHost/Cluckwork.AppHost.csprojno longer references it. Both workaround comments are gone.MessagePack after the change
Only the two AppHost locks contain MessagePack. Both resolve 2.5.307.
src/Cluckwork.AppHosttests/Cluckwork.AppHost.TestsA
--locked-moderestore anddotnet build Cluckwork.slnxboth finish with no warnings, so NuGet audit reports nothing, NU1902 included.MCP comment updates
McpToolErrors.cs:12(SDK 2.2.0 to 2.3.0). At the csharp-sdk v2.3.0 tag,McpServerImpl.cs:1714-1728still logs tool exceptions at Error throughToolCallError(:2531). It skips only a cancellation of the request token andInputRequiredException(:1718).CreateToolCallErrorResult(:1743-1754) still passes the model only anMcpException's message.McpToolErrors.cs:54(Microsoft.Extensions.AI 10.8.3 to 10.11.0). Between the dotnet/extensions v10.8.3 and v10.11.0 tags, the only change inAIFunctionFactory.csis how bind options are keyed: by parameter position instead of byParameterInfoinstance. Argument binding at v10.11.0 (:962-1001) is unchanged. It reads each argument by name with the tool's serializer, and a missing argument takes its default or fails.AIFunctionMcpServerTool.csis identical at v2.2.0 and v2.3.0, so the method is still first inMetadata.Program.cs:255(SDK 2.2.0 to 2.3.0). At v2.3.0,StreamableHttpServerTransport.cs:243still links_transportDisposedCts.Tokenwith the caller's token, and lines 230-250 are identical to v2.2.0.StreamableHttpHandler.cs:190still passescontext.RequestAborted. The:243reference in the comment stays correct.tools/verify/mcp/README.md:10.probe.csstays pinned to 2.2.0. The row called that "the server's SDK", which is no longer true, so it now says the probe is older than the server's SDK and checks that an older client still works.The 2.2.0 references in
docs/decisions/806-mcp-endpoint.mdanddocs/plans/770-mcp-server/stay. They record what I verified at the time.Lock churn I reverted
My first regeneration used
dotnet restore --force-evaluate. That also moved StackExchange.Redis (3.4.5 to 3.4.20) and System.IO.Hashing in five locks that have nothing to do with this change. I reverted those locks and regenerated with--force, which honours the existing locks, so only the two AppHost locks changed.Other places that name MessagePack
CHANGELOG.mdkeeps its entry for the original pin, because it is release history..github/workflows/dependency-submission.yml:23names the advisory as the reason for the daily schedule, not the pin.--locked-modedrift guard inci.ymlchanges Microsoft.OpenApi. The Dockerfile restore layer does not include the AppHost. Neither needs a change.Tests
dotnet build Cluckwork.slnx: 0 warnings, 0 errors.Cluckwork.AppHost.Tests: 10 of 10 passed.Cluckwork.Api.IntegrationTestsfiltered to theMcpnamespace, on Postgres in Testcontainers: 251 of 251 passed.SchemaDocsTests: passed.Related: #1352 tracks when to take MessagePack 3.x. It still applies to the transitive package, and this PR does not close it.