chore(deps): Bump the minor-and-patch group with 4 updates - #349
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps Anthropic from 12.40.0 to 12.42.0 Bumps Aspire.Npgsql from 13.4.6 to 13.5.0 Bumps Marten from 9.25.0 to 9.28.0 Bumps Marten.EntityFrameworkCore from 9.25.0 to 9.28.0 --- updated-dependencies: - dependency-name: Anthropic dependency-version: 12.42.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: Aspire.Npgsql dependency-version: 13.5.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: Marten dependency-version: 9.28.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: Marten.EntityFrameworkCore dependency-version: 9.28.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Dependency ReviewThe following issues were found:
License Issuesbackend/src/RunCoach.Api/RunCoach.Api.csproj
OpenSSF Scorecard
Scanned Files
|
Contributor
Author
|
Looks like these dependencies are updatable in another way, so this is no longer needed. |
dependabot
Bot
deleted the
dependabot/nuget/backend/minor-and-patch-75d849a889
branch
August 27, 2026 15:36
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.
Updated Anthropic from 12.40.0 to 12.42.0.
Updated Aspire.Npgsql from 13.4.6 to 13.5.0.
Release notes
Sourced from Aspire.Npgsql's releases.
13.5.0
Aspire 13.5.0
Aspire 13.5 is a developer-experience release focused on a richer, more interactive AppHost, closer C# and TypeScript parity, sharper tooling, more flexible deployment modeling, and a broad set of runtime-stability improvements.
Highlights
WithTerminal()API lets resources host REPLs, shells, TUIs, and other interactive programs directly in the dashboard, with an opt-inaspire terminalCLI command for attaching from your shell.ASPIREATS001experimental diagnostic and gain custom health checks, container file copying, HTTPS developer certificates, faster startup, and several reliability fixes that further close the gap with C#.aspire stop --force,aspire update --migrate,aspire doctor, docs search, signal handling, and stale-socket cleanup all improve day-to-day workflows.Aspire.Hosting.Dotnetpackage models .NET projects by path; Radius deployment arrives in preview; and Foundry Local, Redis modules, dev tunnels, Go debugging, and other integrations gain new capabilities.Notable changes include hosting context
ServiceProviderproperties being renamed toServices,PublishAsConnectionStringbecoming obsolete in favor ofAddConnectionString, removal ofaspire ps --resourcesand--include-hiddenin favor ofaspire describe, earlier proxyless endpoint port allocation, deprecation of the GitHub Models integration, removal of the dashboard AI Assistant, and opt-in rather than automatic dashboard launch from the VS Code extension.See the full list and migration guidance in the Aspire 13.5 breaking changes.
📖 Learn more
For complete details, examples, migration guidance, and everything new in this release, read What's new in Aspire 13.5.
Thank you to all the community contributors who helped make Aspire 13.5 possible! 💜
Full Changelog: v13.4.6...v13.5.0
Full commit: e076d8e427cb3afb528dbd605acd74c3aea69f94
Commits viewable in compare view.
Updated Marten from 9.25.0 to 9.28.0.
Release notes
Sourced from Marten's releases.
9.28.0
Full Changelog: JasperFx/marten@V9.27.0...V9.28.0
What's Changed
Full Changelog: JasperFx/marten@V9.27.0...V9.28.0
9.27.0
Adopts JasperFx 2.51.0 and the four capabilities it promotes into the shared Critter Stack contracts. One of them is a genuinely new Marten feature; the other three close gaps where Marten had the capability but not under the shared spelling.
Aggregate snapshot caching for
FetchForWriting(#5251)An opt-in, node-local cache of aggregate snapshots that lets
FetchForWritingskip loading the stored snapshot and read only the events after it — effectively an identity map for aggregates with a lifetime longer than a session. Off for every aggregate type; enabled per type, because the win is proportional to how often one stream is fetched for writing:The cached snapshot is only ever a baseline. The stream version and every event after the cached version are still read on every call, and the optimistic concurrency assertion on append is untouched — so a stale entry costs a larger delta query, never a wrong aggregate and never a suppressed
EventStreamUnexpectedMaxEventIdException. That is what makes a deliberately incoherent, node-local cache the right shape here, and why there is no distributed-cache option: a distributed cache would reintroduce exactly the round trip this exists to remove.Both the Async and Inline lifecycles are supported, and they genuinely differ. An Inline snapshot is written in the same transaction as the events, so it is always exactly at the stream head — a hit needs an exact version match, and the entry is written back only after a successful commit, because the inline projection mutates the very instance
FetchForWritinghanded out.IAggregateWriteCacheand friends live inJasperFx.Events.Fetching, so one cache implementation serves Marten, Polecat and Fisher alike. No new package lands on core Marten: the default is backed byJasperFx.Core's existing LRU rather thanMicrosoft.Extensions.Caching.Memory.Docs: Optimizing Performance → Caching Aggregate Snapshots for FetchForWriting.
IDocumentSessionOperations.PendingStreams(#5250)Store-agnostic code can now read the
StreamActions a session has queued but not yet committed — for a listener or a pre-commit hook deciding something from the events the session is about to write — without naming a store.Eventsaccessor. Marten'sPendingChanges.Streams()returnsIList<StreamAction>, andIList<T>is not assignable toIReadOnlyList<T>, so the member bound to the interface's throwing default with no compile error anywhere. It now carries an explicit implementation, pinned byPendingStreamActionsCompliance.In Marten this is the same collection as
IDocumentSession.PendingChanges.Streams(), handed back as a live view rather than a copy.BinaryEventAttribute— one lookup instead of two (#5248)Marten.Events.BinaryEventAttributenow derives from the promotedJasperFx.Events.BinaryEventAttribute, which 2.51.0 unsealed for exactly this.EventGraph.ResolveBinarySerializerFordrops back to a single attribute lookup. Entirely non-breaking — existing[BinaryEvent]usages compile and resolve unchanged.Compliance (#5249)
DocumentComplianceConfig.StreamIdentityis now replayed by Marten's document compliance fixture rather than inferred, and two new shared suites are enrolled:PendingStreamActionsComplianceandAggregateWriteCacheCompliance(wave 10).Upgrading
No breaking changes and no migration. Everything new here is opt-in.
Full changelog: JasperFx/marten@V9.26.0...V9.27.0
9.26.0
Consumes JasperFx 2.50.0, which promoted two things into the shared contracts. Both changes here are additive — existing code compiles and behaves identically.
Reach the event store from a store-agnostic session (jasperfx#669)
JasperFx.Events.Documentsgained anEventsaccessor on its session contracts, so a consumer that opens its own session throughIDocumentSessionFactorycan now reach the event store without naming Marten:IDocumentReadOperationsIQueryEventStore EventsIDocumentSessionOperationsIEventStoreOperations EventsMarten implements both. This does not affect handlers taking a chain parameter — Wolverine already fills those. It matters for the two shapes where you decide when a session exists: a background or timer publisher that opens a session and appends, and a deliberate second read session opened alongside a chain's writing session.
Eventsproperty of its own event-store type does not satisfy the contract member — it binds to a default that throws, and the build still succeeds with zero errors. Marten's ownIQuerySession.EventsreturnsMarten.Events.IQueryEventStore, a subtype, which is exactly this case; both tiers needed an explicit implementation. The shared compliance suite is what catches it.IEventBinarySerializerpromoted toJasperFx.EventsBinary event serialization (#4515) was Marten-specific, so a consumer compiling one body of source against several Critter Stack stores needed a separate identical serializer per store. The two-method interface and
[BinaryEvent]now live inJasperFx.Events, and one serializer serves every store.Non-breaking, in both directions:
Marten.Events.IEventBinarySerializerstill exists and now derives from the core interface, so existing implementations keep compiling and also satisfy the core type.EventGraph.UseBinarySerializer<T>,DefaultBinarySerializer,IEventStoreOptionsandEventMapping.BinarySerializerwidened to accept the core interface, so a store-agnostic serializer can be registered.[BinaryEvent]attributes are honored.Fixed: binary serializer registration was order-dependent
EventMappingresolved its binary serializer in its constructor, andAddEventType<T>()builds mappings eagerly. So this threw"no IEventBinarySerializer was registered"out of what reads as a plain type registration:while the same two lines in the opposite order worked. Resolution is lazy now, deferring the failure to first use — which is what the documentation always described. The guard is
volatile, because it is read from the append path on many threads and a torn read would route a binary event down the JSON path silently rather than throwing.Also
DocumentSessionEventsComplianceandBinaryEventSerializationCompliance.events/binary-serialization.md,documents/sessions.md.Full changelog: JasperFx/marten@9.25.0...9.26.0
Commits viewable in compare view.
Updated Marten.EntityFrameworkCore from 9.25.0 to 9.28.0.
Release notes
Sourced from Marten.EntityFrameworkCore's releases.
9.28.0
Full Changelog: JasperFx/marten@V9.27.0...V9.28.0
What's Changed
Full Changelog: JasperFx/marten@V9.27.0...V9.28.0
9.27.0
Adopts JasperFx 2.51.0 and the four capabilities it promotes into the shared Critter Stack contracts. One of them is a genuinely new Marten feature; the other three close gaps where Marten had the capability but not under the shared spelling.
Aggregate snapshot caching for
FetchForWriting(#5251)An opt-in, node-local cache of aggregate snapshots that lets
FetchForWritingskip loading the stored snapshot and read only the events after it — effectively an identity map for aggregates with a lifetime longer than a session. Off for every aggregate type; enabled per type, because the win is proportional to how often one stream is fetched for writing:The cached snapshot is only ever a baseline. The stream version and every event after the cached version are still read on every call, and the optimistic concurrency assertion on append is untouched — so a stale entry costs a larger delta query, never a wrong aggregate and never a suppressed
EventStreamUnexpectedMaxEventIdException. That is what makes a deliberately incoherent, node-local cache the right shape here, and why there is no distributed-cache option: a distributed cache would reintroduce exactly the round trip this exists to remove.Both the Async and Inline lifecycles are supported, and they genuinely differ. An Inline snapshot is written in the same transaction as the events, so it is always exactly at the stream head — a hit needs an exact version match, and the entry is written back only after a successful commit, because the inline projection mutates the very instance
FetchForWritinghanded out.IAggregateWriteCacheand friends live inJasperFx.Events.Fetching, so one cache implementation serves Marten, Polecat and Fisher alike. No new package lands on core Marten: the default is backed byJasperFx.Core's existing LRU rather thanMicrosoft.Extensions.Caching.Memory.Docs: Optimizing Performance → Caching Aggregate Snapshots for FetchForWriting.
IDocumentSessionOperations.PendingStreams(#5250)Store-agnostic code can now read the
StreamActions a session has queued but not yet committed — for a listener or a pre-commit hook deciding something from the events the session is about to write — without naming a store.Eventsaccessor. Marten'sPendingChanges.Streams()returnsIList<StreamAction>, andIList<T>is not assignable toIReadOnlyList<T>, so the member bound to the interface's throwing default with no compile error anywhere. It now carries an explicit implementation, pinned byPendingStreamActionsCompliance.In Marten this is the same collection as
IDocumentSession.PendingChanges.Streams(), handed back as a live view rather than a copy.BinaryEventAttribute— one lookup instead of two (#5248)Marten.Events.BinaryEventAttributenow derives from the promotedJasperFx.Events.BinaryEventAttribute, which 2.51.0 unsealed for exactly this.EventGraph.ResolveBinarySerializerFordrops back to a single attribute lookup. Entirely non-breaking — existing[BinaryEvent]usages compile and resolve unchanged.Compliance (#5249)
DocumentComplianceConfig.StreamIdentityis now replayed by Marten's document compliance fixture rather than inferred, and two new shared suites are enrolled:PendingStreamActionsComplianceandAggregateWriteCacheCompliance(wave 10).Upgrading
No breaking changes and no migration. Everything new here is opt-in.
Full changelog: JasperFx/marten@V9.26.0...V9.27.0
9.26.0
Consumes JasperFx 2.50.0, which promoted two things into the shared contracts. Both changes here are additive — existing code compiles and behaves identically.
Reach the event store from a store-agnostic session (jasperfx#669)
JasperFx.Events.Documentsgained anEventsaccessor on its session contracts, so a consumer that opens its own session throughIDocumentSessionFactorycan now reach the event store without naming Marten:IDocumentReadOperationsIQueryEventStore EventsIDocumentSessionOperationsIEventStoreOperations EventsMarten implements both. This does not affect handlers taking a chain parameter — Wolverine already fills those. It matters for the two shapes where you decide when a session exists: a background or timer publisher that opens a session and appends, and a deliberate second read session opened alongside a chain's writing session.
Eventsproperty of its own event-store type does not satisfy the contract member — it binds to a default that throws, and the build still succeeds with zero errors. Marten's ownIQuerySession.EventsreturnsMarten.Events.IQueryEventStore, a subtype, which is exactly this case; both tiers needed an explicit implementation. The shared compliance suite is what catches it.IEventBinarySerializerpromoted toJasperFx.EventsBinary event serialization (#4515) was Marten-specific, so a consumer compiling one body of source against several Critter Stack stores needed a separate identical serializer per store. The two-method interface and
[BinaryEvent]now live inJasperFx.Events, and one serializer serves every store.Non-breaking, in both directions:
Marten.Events.IEventBinarySerializerstill exists and now derives from the core interface, so existing implementations keep compiling and also satisfy the core type.EventGraph.UseBinarySerializer<T>,DefaultBinarySerializer,IEventStoreOptionsandEventMapping.BinarySerializerwidened to accept the core interface, so a store-agnostic serializer can be registered.[BinaryEvent]attributes are honored.Fixed: binary serializer registration was order-dependent
EventMappingresolved its binary serializer in its constructor, andAddEventType<T>()builds mappings eagerly. So this threw"no IEventBinarySerializer was registered"out of what reads as a plain type registration:while the same two lines in the opposite order worked. Resolution is lazy now, deferring the failure to first use — which is what the documentation always described. The guard is
volatile, because it is read from the append path on many threads and a torn read would route a binary event down the JSON path silently rather than throwing.Also
DocumentSessionEventsComplianceandBinaryEventSerializationCompliance.events/binary-serialization.md,documents/sessions.md.Full changelog: JasperFx/marten@9.25.0...9.26.0
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions