[Snyk] Upgrade monaco-editor from 0.32.1 to 0.45.0 by ekaterinamishina · Pull Request #7 · Systemorph/MeshWeaver

ekaterinamishina · 2024-02-28T05:37:58Z

Snyk has created this PR to upgrade monaco-editor from 0.32.1 to 0.45.0.

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.

The recommended version is 531 versions ahead of your current version.
The recommended version was released 3 months ago, on 2023-12-07.

Release notes

Package name: monaco-editor

from monaco-editor GitHub release notes

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

Snyk has created this PR to upgrade monaco-editor from 0.32.1 to 0.45.0. See this package in npm: https://www.npmjs.com/package/monaco-editor See this project in Snyk: https://app.snyk.io/org/ekaterinamishina/project/a7ae825a-a391-4cf6-9734-4f788c3f8223?utm_source=github&utm_medium=referral&page=upgrade-pr

…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>

…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>

ekaterinamishina assigned akravets-sm Feb 28, 2024

psurdulli unassigned akravets-sm Jul 11, 2024

rbuergi closed this Oct 7, 2024

rbuergi deleted the snyk-upgrade-1d5404a6b321ed654dba211781514f27 branch October 7, 2024 16:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Snyk] Upgrade monaco-editor from 0.32.1 to 0.45.0#7

[Snyk] Upgrade monaco-editor from 0.32.1 to 0.45.0#7
ekaterinamishina wants to merge 1 commit into
mainfrom
snyk-upgrade-1d5404a6b321ed654dba211781514f27

ekaterinamishina commented Feb 28, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

ekaterinamishina commented Feb 28, 2024

Snyk has created this PR to upgrade monaco-editor from 0.32.1 to 0.45.0.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants