Repository navigation
fix(create): a stalled validators stage names the validator it waits on (#6391) - #6421
Merged
Merged
Conversation
…on (#6391) The create chain runs every INodeValidator in sequence, and its stalled verdict said only "stage 'validators'". On memex it fired ten times in three minutes on a freshly booted pod for System-written creates, where every core validator answers synchronously, so the reading could not say which validator was silent, or whether the chain stalled before any was asked. The stage now reads 'validators: resolving' while the scoped validators are constructed, then 'validators: <Type> (i/n)' from the moment the chain subscribes to each, on the verdict and the fate trail. Refs #6391 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused diagnostic change is correctly composed, documented, and covered by an appropriate regression assertion.
0 open findings
What changed in this PR
Adds validator-level diagnostics to stalled create operations without changing validation behavior.
Changes:
- Reports validator resolution and per-validator progress.
- Extends regression coverage for named stalled validators.
- Documents the enhanced lifecycle verdict and fate trail.
| File | Description |
|---|---|
src/MeshWeaver.Mesh.Contract/MeshExtensions.cs |
Tracks validator-specific create stages. |
test/MeshWeaver.Hosting.Test/LifecycleRequestsAlwaysReachAVerdictTest.cs |
Verifies stalled verdicts name the validator. |
src/MeshWeaver.Documentation/Data/Architecture/WriteVerdictTotality.md |
Documents validator-stage diagnostics. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
Test Results 19 files 19 suites 51m 48s ⏱️ Results for commit dd2f99a. ♻️ This comment has been updated with latest results. |
This was referenced Oct 10, 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
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.
Refs #6391 · Refs #6393
What
A create whose chain stalls in the validators stage now names the validator it was waiting on.
validators: resolvingwhile the scoped validators are constructed (DI).validators: <TypeName> (i/n)from the moment theConcatsubscribes to each validator.LifecycleVerdictStalledException) and on the fate trail (CREATE_STAGE …).Why this and not a "fix" of the stall itself
On memex.systemorph.com, #6391 fired ten times in three minutes on one freshly booted pod (
memex-portal-deployment-5f6b9fc9b-hrdhq, 2026-10-09 20:36–20:39Z). The creates were all System-written:Admin/_Notification/…,Admin/PlatformVersion/_Activity/startup-…,Doc/_Activity/import-…,Admin/_LogIncident/site-….I read every core validator's
Validate. For a System write each one answers with a synchronousObservable.Return. RLS and PartitionWriteGuard bypass System, CreatableTypes exempts platform writers, and the static-type branch of OwnsPartitionProvisioning returns at once. So the code alone cannot explain a 30 s silence in that stage. Governed Logs readOps/Actions/logs-memex-20261010-6391-validators-window(control, podhrdhq, 12 h, 35 lines, not cut) found none of the inner terminals a slow validator would print: noRLS: … could NOT be established, no[CreatableTypes] … could not be read, noQueryProviderStalledException. The bare stage name could not even tell "a validator never answered" from "the chain stalled before any validator was asked", for example a blocked DI construction.Without that reading any root-cause change would be a guess. This PR makes the next occurrence name its culprit. #6391 stays open for that reading.
#6393 is a downstream casualty of the same window: its bell-node create was the tenth victim.
Test
LifecycleRequestsAlwaysReachAVerdictTest.ACreateWhoseValidatorNeverAnswers_IsAnsweredUnavailable_NamingTheStagenow also asserts that the verdict containsvalidators: SilentCreationValidator (.…it was still waiting at stage 'validators'….MeshWeaver.Mesh.Contract,MeshWeaver.Hosting.TestandMeshWeaver.Documentationbuild clean with-c Release -warnaserror.Doc
Doc/Architecture/WriteVerdictTotality: the stage table and a new paragraph on the per-validator stage.Recycle
None needed. The change is in the node-operations handler, which ships with the image.
🤖 Generated with Claude Code