moved canEdit and canRun permissions to props#6
Closed
avinokurovSystemorph wants to merge 5 commits into
Closed
Conversation
Test Results109 tests ±0 104 ✅ ±0 22s ⏱️ ±0s For more details on these failures, see this check. Results for commit 316245d. ± Comparison against base commit 821436f. ♻️ This comment has been updated with latest results. |
akravets-sm
approved these changes
Jan 31, 2024
akravets-sm
reviewed
Feb 5, 2024
rbuergi
added a commit
that referenced
this pull request
May 3, 2026
… TestUser Bulk update across 18 Orleans test files + OrleansTestSeedProvider so TestUser lives at root namespace consistently. Aligned with the post-v10 user-partition design (see UserNodeType.RestrictedToNamespaces=['']). ChatHistory test now passes locally; Markdown export tests still fail on a separate per-node-grain activation/routing issue tracked under #6. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
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
3 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.
removed some of project deps in notebookEditor