Repository navigation
[Snyk] Upgrade @microsoft/signalr from 3.1.9 to 3.1.31 - #10
Closed
ekaterinamishina wants to merge 1 commit into
Closed
ekaterinamishina wants to merge 1 commit into
ekaterinamishina wants to merge 1 commit into
Conversation
Snyk has created this PR to upgrade @microsoft/signalr from 3.1.9 to 3.1.31. See this package in npm: https://www.npmjs.com/package/@microsoft/signalr See this project in Snyk: https://app.snyk.io/org/ekaterinamishina/project/32d42d2f-d47d-44c2-ba87-4ca15b82ee07?utm_source=github&utm_medium=referral&page=upgrade-pr
rbuergi
added a commit
that referenced
this pull request
May 5, 2026
…leasePath is set Tasks #6, #7, #8, #9, #10, #11, #12, #13, #14 from the failing-tests list share one root cause: NodeTypeContractHandler.Handle was short-circuiting on node.AssemblyLocation alone. For freshly-created dynamic NodeTypes (NodeType=NodeType, Content=NodeTypeDefinition), NodeTypeService .EnrichWithNodeType propagates the STATIC "NodeType" type's framework DLL (MeshWeaver.Graph.dll) onto the new node's AssemblyLocation through its fast-path ApplyEntry. The handler then opened MeshWeaver.Graph.dll, found no MeshNodeProvider for the new hub's path, and silently returned Success=true with empty NodeTypeConfigurations — so: - CompileFailsWhenSourceCodeIsInvalid sees Success=true (compile never actually ran). - CompileWithMultipleSourceLocationsPullsInExternalCode misses the external Profile type for the same reason. - CompileActivityLogTest.* never produces an activity log because the Roslyn compile never ran. - LinkedIn* tests can't render their NodeType-bound layout areas. - MeshPluginTest broken-NodeType tests don't see the compile error because no compile happened. Fix: only take the short-circuit path when def.LatestReleasePath is non-empty. A populated LatestReleasePath means StartCompile (or a release publish) has actually emitted an assembly for THIS NodeType; only then is AssemblyLocation a real release DLL. Otherwise fall through to compilationService.CompileAndGetConfigurations, which runs Roslyn, returns the real Success/Failed shape, and lets the cluster behave. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
rbuergi
added a commit
that referenced
this pull request
May 10, 2026
…ThreadExecution stability fixes ThreadExecution.cs (already in commit 478fdaa — recapping here for the review-item index): - RecoverStaleExecutingThread: drop the 2-minute "fresh execution" window in favour of a structural check (skip when PendingUserMessage + ActiveMessageId are still set, i.e. the thread is an auto-execute candidate WatchForExecution will pick up). Closes the "long-running agent crashed at minute 5 → IsExecuting=true forever" gap; the time-based heuristic contradicted commit 6dc436b's "no time limits" stance. - Subject<StreamingSnapshot>: declare with `using var` so the Subject itself disposes alongside its subscription. Minor leak per execution previously. - HandleSubmitMessage: pre-allocate the per-round CancellationTokenSource and store it on the thread hub BEFORE posting SubmitMessageResponse — closes the race where an early Stop click between IsExecuting=true and ExecuteMessageAsync's `parentHub.Set(executionCts)` found a null CTS slot and silently no-op'd. ExecuteMessageAsync now reuses the pre-allocated CTS (with a fallback for the auto-execute path that bypasses HandleSubmitMessage). IsExecutingLifecycleTest.cs: - Migrate the response-text wait from text-pattern matching (skipping placeholders "Allocating agent..." etc.) to `ThreadMessage.CompletedAt is not null`, which ExecuteMessageAsync sets only on the terminal PushToResponseMessage call. Same pattern adopted in ChatHistoryTest in commit ab3af8b. - Add a regression assertion that final ThreadMessage.Status == Completed. The terminal-status guard in PushToResponseMessage prevents the late Sample(100ms)-flushed Streaming push from regressing the cell from Completed back to Streaming; this assertion catches any future regression of that guard. Addresses PR #95 review items #5, #6, #7, #8, #10. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rbuergi
added a commit
that referenced
this pull request
May 18, 2026
All callers (production + 19 test sites) now invoke the production helpers
directly (ThreadSubmission.Submit / ApplyResubmit / ApplyDeleteFromMessage /
ApplyRecordSubmissionFailure, ThreadInput.AppendUserInput, or
workspace.GetMeshNodeStream(threadPath).Update for RequestedCancellationAt).
The legacy request types and their type-registry entries are now gone:
Deleted:
src/MeshWeaver.AI/AppendUserMessageRequest.cs
(AppendUserMessageRequest, AppendUserMessageResponse,
ResubmitUserMessageRequest, RecordSubmissionFailureRequest)
src/MeshWeaver.AI/CancelThreadStreamRequest.cs
(CancelThreadStreamRequest, CancelThreadStreamResponse)
src/MeshWeaver.Layout/ThreadMessageActionRequests.cs
(ResubmitMessageRequest, DeleteFromMessageRequest)
The last surviving thread-mutation request is SubmitMessageRequest — its
handler pre-allocates a CancellationTokenSource that the pure stream-update
path can't replicate without a side-effect watcher. Tracked separately
(task #10) for the next sweep.
Tests migrated as part of this commit:
- ThreadSubmissionIntegrationTest: RecordSubmissionFailureRequest →
ThreadSubmission.ApplyRecordSubmissionFailure.
- OrleansThreadAccessTest (two sites): AppendUserMessageRequest →
ThreadSubmission.Submit, including the permission-denied case which
now uses SubmitContext.OnError (same callback ThreadChatView uses).
Build green (only pre-existing Humanizer NuGet restore issue on Content.Test).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rbuergi
added a commit
that referenced
this pull request
Sep 5, 2026
…para Three corrections to the guards and their prose, none to the fix itself. 1. Both parsers bounded the probe block as "up to the next *Probe:" line. The LIVENESS probe is the last one in the template, so its body ran to EOF and the first httpGet after it was its own only by luck of ordering -- a sidecar probe added later would have been read as the liveness path, and the guard would then assert about something else entirely while still passing. A guard that can silently change subject is the exact failure class this change is about. Both now capture only lines indented DEEPER than the probe key. Re-proven after the change: chart readiness back to /alive still reds all three ProbeSemanticsGuard cases and both ProbeSeparationTest cases, with the same messages. 2. check-chart-invariants.sh listed the new probe-separation rule as #9 while check-chart-invariants.py numbers it #10 (the .sh list was missing the never-blank rule at #9 entirely). Numbers now agree, so a CI error message cross-references. Reported by Copilot review on #3332. 3. ProbeEndpoints.cs nested a <para> inside a <para>. Unnested. Same review. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 7, 2026
Merged
rbuergi
added a commit
that referenced
this pull request
Sep 8, 2026
…MethodTable fingerprint Recurrence triage of `Portal hosts (shard 1)` SIGSEGV in MeshWeaver.Plugins (runs 34069990582 and 34210183539). Both cores were parsed end to end; no cause was named before reading them. The pair is more informative than either dump alone because they disagree on every incidental and agree on the invariant: - #11 `MeshWeaver.GitSync.Test`, on `main`: si_addr=0x4, `LCGMethodResolver::GetCodeInfo+0x1f7`, mutator thread inside the JIT. - #12 `MeshWeaver.FutuRe.Test`: si_addr=0x0, `WKS::gc_heap::background_sweep()+0xa61`, dedicated BGC thread, no managed frame. - Both: `mov (%r15),%rax` loading a MethodTable word that reads exactly zero (confirmed at source — the bytes at R15 are zero in both cores), then a read off it at whichever field offset the caller wanted. So `si_addr` is measured, not merely argued, to be no part of the fingerprint; and the frame REVISITS rather than progressing — 0x5cb171 was already on sighting #9's table. Sighting #10's "the family is the LCG/serialization workload" consequence is marked superseded in part. Base rate re-measured over 2026-09-06 -> 09-08: 4 occurrences in a denominator of 343 runs whose portal-host shard reached a verdict (1.17 %), two of them on `main`. Flagged explicitly as NOT comparable to the earlier 0.74 %, which used a different denominator. Also recorded, so the next reader need not re-derive them: FutuRe.Test has no ProjectReference to MeshWeaver.AI (directly or via Hosting.Monolith.TestBase), and this is independent of the platform-pin staleness redding Plugins PRs. No fix is proposed and nothing is reopened — this remains the upstream zeroed-MethodTable family owned by #613. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 19, 2026
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
4 participants
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.
Snyk has created this PR to upgrade @microsoft/signalr from 3.1.9 to 3.1.31.
As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
✨ Snyk has automatically assigned this pull request, set who gets assigned.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
Release notes
Package name: @microsoft/signalr
-
3.1.31 - 2022-11-08
-
3.1.30 - 2022-10-11
-
3.1.29 - 2022-09-13
-
3.1.28 - 2022-08-09
-
3.1.27 - 2022-07-12
-
3.1.26 - 2022-06-14
-
3.1.25 - 2022-05-10
-
3.1.24 - 2022-04-12
-
3.1.23 - 2022-03-08
-
3.1.22 - 2021-12-14
-
3.1.21 - 2021-11-08
-
3.1.20 - 2021-10-12
-
3.1.19 - 2021-09-14
-
3.1.18 - 2021-08-10
-
3.1.17 - 2021-07-13
-
3.1.16 - 2021-06-08
-
3.1.15 - 2021-05-11
-
3.1.14 - 2021-04-08
-
3.1.13 - 2021-03-09
-
3.1.12 - 2021-02-09
-
3.1.11 - 2021-01-12
-
3.1.10 - 2020-11-09
-
3.1.9 - 2020-10-13
from @microsoft/signalr GitHub release notesRelease
Release
Release
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
👩💻 Set who automatically gets assigned
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs