Repository navigation
CreateNode lifecycle stalls at the validators stage with no verdict — a validator never answers within its window during the platform-startup boot-activity create #6391
Description
What is failing. The CreateNode lifecycle verdict pipeline (MeshWeaver.Mesh.MeshExtensions, category MeshWeaver.Mesh.CreateNode) waits on a staged verdict before committing. For the boot-activity create issued by platform startup (Admin/PlatformVersion/_Activity/startup-380439f5 — the [PlatformStartup] boot recording), no verdict arrived within the 30 s window while the request sat at the validators stage. Nothing refused the request, so a validator either never answered or its answer was lost — the create's fate is unknown, which is why the message tells the reader to re-read the target before retrying.
Probable cause — moderate confidence, not pinned. The evidence (a single log line, no stack into the validator stage) supports a lost-or-never-minted validator verdict rather than a validation failure, but cannot distinguish between the two families that fit:
- Boot ordering. The node is created during platform startup; a validator whose partition, NodeType activation or cross-hub stream is not yet ready at that instant may simply never post a verdict within the window.
- Verdict-loss seams of the kind documented for the write path in Reading a Write Verdict — a stage watcher without a completion arm, or the responder being a single-threaded grain activation whose own turn cannot route the verdict round-trip it is waiting on (the silent-deadlock shape also described in Activity Control Plane).
Impact. Single occurrence on one pod in the memex deployment, during a platform boot. What is at stake is the boot-activity audit record: one boot's startup activity may be missing or incomplete, and the node may or may not have landed after the window. No user-facing path is known to be affected. Judged sev:M; a human may re-rule if this recurs across boots or the node is confirmed lost.
Where to look.
MeshWeaver.Mesh.MeshExtensions— the CreateNode staged-verdict machinery andLifecycleVerdictStalledException: the stage registry that namesvalidators, what arms (and re-arms) the wait per validator, and whether every validator path posts exactly one terminal even when it completes without emitting.- The
[PlatformStartup]boot-recording path that creates theAdmin/PlatformVersion/_Activity/startup-…node — why a boot-time create runs while validators may not be fully armed, and whether the boot recording survives the stall. - Reading a Write Verdict and Activity Control Plane — the documented verdict-loss patterns the validator stage should be checked against.
- Before retrying or closing: read
Admin/PlatformVersion/_Activity/startup-380439f5to learn whether the node actually landed.
Evidence
| Fingerprint | 832b105be8c96fa4 |
| Category | MeshWeaver.Mesh.CreateNode |
| Severity | Error |
| Namespace | memex |
| Pods | memex-portal-deployment-5f6b9fc9b-hrdhq |
| Occurrences | 1 |
| First seen | 2026-10-09 20:36:30Z |
| Last seen | 2026-10-09 20:36:30Z |
| Routing | not determined — no configured route matches the category MeshWeaver.Mesh.CreateNode. This repository is the configured fallback, not a finding about who owns the fault; the category names the LOGGER, which may not be the subject. |
Recent log lines
2026-10-09 20:36:30Z memex-portal-deployment-5f6b9fc9b-hrdhq fail: MeshWeaver.Mesh.CreateNode[0]
[CreateNode] Admin/PlatformVersion/_Activity/startup-380439f5 reached no verdict within 30s — stalled at stage validators
MeshWeaver.Mesh.MeshExtensions+LifecycleVerdictStalledException: CreateNode of 'Admin/PlatformVersion/_Activity/startup-380439f5' reached no verdict within 30s: it was still waiting at stage 'validators'. Nothing refused the request; whether the stage's own work lands later is unknown, so read the target before retrying.
Opened automatically from Admin/_LogIncident/832b105be8c96fa4. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site f205e0da8dbd21ba: other fingerprints of this site fold in here as comments rather than opening tickets of their own.
Activity
systemorph-com commentedon Oct 9, 2026
Still occurring: 2 more since the last update (3 total).
memex-portal-deployment-5f6b9fc9b-hrdhqRecent log lines
systemorph-com commentedon Oct 10, 2026
Still occurring: 7 more since the last update (10 total).
memex-portal-deployment-5f6b9fc9b-hrdhqRecent log lines
rbuergi commentedon Oct 10, 2026
Status 2026-10-10: the cause is not pinned. #6421 makes the next occurrence name it.
What the code says. For a System-written create, every core
INodeValidatoranswers with a synchronousObservable.Return:All ten stalled creates were System writes:
Admin/_Notification/…×6,Admin/PlatformVersion/_Activity/startup-380439f5,Doc/_Activity/import-0684c4f2ab825e65×2,Admin/_LogIncident/site-f205e0da8dbd21ba. So no validator's own read explains 30 s of silence. The candidates left are:What the logs say. Governed Logs read
Ops/Actions/logs-memex-20261010-6391-validators-windowon control (podmemex-portal-deployment-5f6b9fc9b-hrdhq, 12 h, 35 lines, not cut): the ten stall lines, the[StaticRepoImport] Doc … UpsertRefusedExceptionfollow-on,[FanOut] GRACElines, and none of the inner terminals a slow validator prints. That means noRLS: … could NOT be established, no[CreatableTypes] … could not be read, and noQueryProviderStalledException.What changes. #6421 refines the stage on the verdict and on the fate trail:
validators: resolvingwhile the validators are constructed;validators: <TypeName> (i/n)from the moment the chain subscribes to each one.Test:
LifecycleRequestsAlwaysReachAVerdictTest. Negative control: the test fails on the pre-change code, whose verdict says onlyvalidators.Close condition. After #6421 is live on memex, the next occurrence names its stage detail. Fix that site at the root. If a boot window passes with no recurrence, read it against pod starts.
#6393 is closed as a duplicate of this issue: its bell create was the tenth victim of the same window.
Give every creation validator exactly one bounded verdict
Merge pull request #6421 from Systemorph/fix/6391-validator-stage-ver…
systemorph-com commentedon Oct 10, 2026
Folded in — a DIFFERENT fingerprint from the same log site.
This issue tracks the log site
f205e0da8dbd21ba(MeshWeaver.Mesh.CreateNode), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.d642f283bfe499d8f205e0da8dbd21baMeshWeaver.Mesh.CreateNode[CreateNode] {path} was written, but its post-creation handlers had not finished within {n}s — answering '{value}'memex-cloudmemex-portal-deployment-85587f8869-5j9gxAdmin/_LogIncident/d642f283bfe499d8What triage wrote about this fingerprint
What is failing
MeshWeaver.Mesh.CreateNode(theMeshExtensionsCreateNode handler) couples its response to the post-creation handler chain: the node is written to the store first, but the answer to the caller is only produced after all post-creation handlers finish. When they exceed the fixed 30 s budget, the caller receives anoutcome unknownanswer for a create that actually succeeded.Probable cause
High confidence in the mechanism, medium confidence in the trigger. The failing create is the platform's own startup activity node, created on a freshly started portal pod; sibling incidents in the same window show the NodeType bake health check Unhealthy and compilation failures on the same pod, so the post-creation handlers were almost certainly queued behind startup-time NodeType baking/compilation work and missed the fixed 30 s budget. The defect is the answer/handler coupling itself — not the slow handlers — and it is the same mechanism already analyzed in Systemorph/MeshWeaver#6039 (webhook deliveries answered 500 because the endpoint awaited this same CreateNode path past its deadline). That issue's candidate direction — answer once the store has committed rather than after the post-creation handlers — would eliminate this failure mode too.
Impact
Single occurrence on a single pod, at startup. The node was written; nothing was lost. The concrete harm is limited to the ambiguous answer, but any caller that retries on
outcome unknownrisks duplicating the create, or reporting a spurious failure for work that succeeded. Judgedsev:Lfrom the numbers (rare, single instance, easy to re-check by hand); a human may want to re-rule upward given the shared mechanism with #6039.Where to look
MeshWeaver.Mesh.MeshExtensions— the CreateNode handler: the post-creation handler chain and the 30 s timeout that decides between a real answer andoutcome unknown. Related and likely the umbrella fix: Systemorph/MeshWeaver#6039 (area:hosting, still open).Still occurring: 2 more since the last update (2 total).
memex-portal-deployment-85587f8869-5j9gxRecent log lines
systemorph-com commentedon Oct 10, 2026
Still occurring: 10 more since the last update (12 total).
memex-portal-deployment-85587f8869-5j9gx,memex-portal-deployment-8c87bbfc-gvt4nRecent log lines
systemorph-com commentedon Oct 10, 2026
Still occurring: 1 more since the last update (13 total).
memex-portal-deployment-85587f8869-5j9gx,memex-portal-deployment-8c87bbfc-gvt4n,memex-portal-deployment-5499f76b76-ltlwcRecent log lines
systemorph-com commentedon Oct 10, 2026
Still occurring: 1 more since the last update (13 total).
memex-portal-deployment-85587f8869-5j9gx,memex-portal-deployment-8c87bbfc-gvt4n,memex-portal-deployment-5499f76b76-ltlwcRecent log lines
rbuergi commentedon Oct 10, 2026
2026-10-10 ~20:45Z post-roll reading: #6421 is live, and no stall names a validator. Every stall is in the post-creation handlers, on memex-cloud, at boot.
Running. memex and memex-cloud both read core
d2f068a1fb; #6421 (64bbff2e3c, merged 07:00Z) is an ancestor.Logs (governed
Logson control, query\[CreateNode\].*(validators|post-creation handlers|outcome unknown), 06:41Z to 20:41Z, neither cut):Ops/Actions/logs-memexcloud-20261010-2055-va-create): 18 lines, on three pods:85587f8869-5j9gx(08:10Z to 08:16Z),8c87bbfc-gvt4n(08:39Z to 08:45Z),5499f76b76-ltlwc(18:10Z to 18:16Z). Every line I read has the form[CreateNode] <path> was written, but its post-creation handlers had not finished within 30s — answering 'outcome unknown'. The targets areAdmin/PlatformVersion/_Activity/startup-…first, thenAdmin/_Notification/…at about 70 s intervals.Ops/Actions/logs-memex-20261010-2050-va-create): 0 lines in the same window, over at least three rolls. The memex-cloud result is the positive control for the query.validators: resolvingorvalidators: <TypeName>.What that changes. The title's stage is no longer where the request waits. On today's images the node IS written, and what does not finish within 30 s is the post-creation handler chain, in a burst of about six minutes after each pod start, and only on memex-cloud. So the next step is to find which post-creation handler for
Admin/PlatformVersion/_ActivityandAdmin/_Notificationdoes not complete during boot on memex-cloud (and why memex, on the same core, shows none).Not established: whether these 18 are the same defect as the ten original
validatorsstalls with the stage now reported more precisely, or a second defect that #6421's finer stage reporting uncovered. Nothing was changed. Still occurring, so this stays open.rbuergi commentedon Oct 10, 2026
2026-10-10 ~21:15Z: where the post-creation leg waits, a repro of the production line, and what is still open. PR #6455.
Readings (governed read-only
Logson control, podmemex-portal-deployment-5499f76b76-ltlwc, actionsOps/Actions/logs-memexcloud-20261010-w14b-boot-ltlwcand…-ltlwc-2to…-ltlwc-7):[PlatformStartup]begins; 18:10:20.031 the last hosted service to log a start (DynamicTypePreWarmer)Node created at Admin/PlatformVersion/_Activity/startup-79c03bd1(about 365 ms after the request)… CREATE_STAGE write (+311ms) → CREATE_CHAIN_EMITTED (+365ms) → CREATE_POST_HANDLERS_START (+365ms), then nothing. Hub pumpidle buffer=0.was written, but its post-creation handlers had not finished within 30sAdmin/_Notification/…creates, each written within about 100 ms and each stalling the same waycreatedumpruns; the process is replacedstartup complete11 ms later,Application started40 ms after thatThe first process never logged
Application started. No line readingreached no verdict … stalled at stageaccompanies any of the six.Which handler. None applies to these node types. The four in core are for
User,Space, the sync config and non-static partition roots; the three MeshWeaver.AI registers are all forUser. For a node no handler applies to, the leg only resolves the registrations and asks each one'sMatches. A handler a module registered is a forwarding proxy, and every call on it,Matchesincluded, first resolves the module's instance from the module's own container. So the wait is in resolve-or-match, and it is a wait on a container, not on a handler's work. This is an inference by elimination, not a reading: no log line carries a stack.Repro.
ACreateWaitsOnAModuleContainerUnderConstructionTestloads a real module into its own container, parks the construction of one of its singletons, and creates an unrelated node as System. On the unchanged code it writes the production line byte for byte (… was written, but its post-creation handlers had not finished within 6s — answering 'outcome unknown'). With the change it reads(waiting at post-creation-handlers: matching INodePostCreationHandler [module MeshWeaver.Test.HeldContainer, registration 0] (4/4)), and the module's handler was never built.What PR #6455 changes. The leg names its stage (
resolving,matching <handler> (i/n),<handler> (i/n),… additional nodes), a module's proxy is named by module and registration without resolving it, and two defects the repro exposed are corrected: the 'outcome unknown' line could be written for a create answeredOk, and a leg that returned late was followed by a second, falsestalled at stage writeline. No timeout changes.Still open, and what would settle it.
AnalyzeDumpis not on the control instance yet: a create withdumpPodwas refused (unknown content member(s) 'dumpPod' for type InstanceActionContent), nothing was written. Once control runs a build that has it,{ "requestedAction": "AnalyzeDump", "dumpPod": "memex-portal-deployment-5499f76b76-ltlwc" }againstDeployments/memex-cloudreads it.Doc/Architecture/ReadingASiloEvictionlists this create line. Correlated, not established.waiting atclause saysresolvingor names the module. That is the reading that confirms or refutes the inference above.Details are in
Doc/Architecture/WriteVerdictTotality("The post-creation leg names what it is waiting on, too").fix(create): discovering a handler's additional nodes is its own stag…
fix(create): post the post-creation verdict before logging it; a prox…
systemorph-com commentedon Oct 11, 2026
Still occurring: 5 more since the last update (18 total).
memex-portal-deployment-85587f8869-5j9gx,memex-portal-deployment-8c87bbfc-gvt4n,memex-portal-deployment-5499f76b76-ltlwcRecent log lines
systemorph-com commentedon Oct 11, 2026
Folded in — a DIFFERENT fingerprint from the same log site.
This issue tracks the log site
f205e0da8dbd21ba(MeshWeaver.Mesh.CreateNode), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.31f12aedfc4bbbc8f205e0da8dbd21baMeshWeaver.Mesh.CreateNode[CreateNode] {path} was written, but its post-creation handlers had not finished within {n}s (waiting at post-creation-handlers: resolving) — answering '{value}'memexmemex-portal-deployment-6749fbfc59-hdlgzAdmin/_LogIncident/31f12aedfc4bbbc8What triage wrote about this fingerprint
What is failing
When the portal records its boot-activity node (
Admin/PlatformVersion/_Activity/startup-*) during startup, the create request is answered with an unknown outcome: the node itself is written, but the create pipeline's post-creation handlers — still in the resolving phase — have not completed within the 30s budget. This is the platform's own startup bookkeeping write, on a single pod.Probable cause — medium confidence
Boot-time contention in the resolving phase of post-creation handling. The same hour the fleet logged heavy silo churn (multiple
Orleans.Runtime.SiloUnavailableExceptionroll-churn incidents on the memex namespaces around 03:05–03:54 UTC), so the resolving phase plausibly waited on a busy or restarting silo during portal boot. The write itself succeeded — this is a late completion signal, not a lost or rolled-back write. Cause is not established from one sample; if resolving regularly stalls >30s at boot there may be a real bottleneck worth naming.Impact
Single occurrence on a single pod; no user-visible failure and no data loss. The risk this exposes is a caller treating the unknown outcome as failure and re-creating the activity node — exactly the retry-after-timeout hazard the unknown-outcome contract (shipped 2026-09-09, see Create timeouts report an unknown outcome) was designed to flag.
Where to look
MeshWeaver.Mesh.CreateNode, stagepost-creation-handlers: resolving— and what that phase resolves at boot.[PlatformStartup]writes toAdmin/PlatformVersion/_Activity/startup-*), which issues this create during the boot sequence.Still occurring: 1 more since the last update (1 total).
memex-portal-deployment-6749fbfc59-hdlgzRecent log lines
systemorph-com commentedon Oct 11, 2026
Folded in — a DIFFERENT fingerprint from the same log site.
This issue tracks the log site
f205e0da8dbd21ba(MeshWeaver.Mesh.CreateNode), and these occurrences belong to it. They carry their own fingerprint — the masking split one site across several — so before this they would have opened a SEPARATE ticket. One log site fanned out into 46 of those, which is why they fold here instead. Nothing is discarded: the distinguishing evidence is below, and splitting this back out is a person's call.31f12aedfc4bbbc8f205e0da8dbd21baMeshWeaver.Mesh.CreateNode[CreateNode] {path} was written, but its post-creation handlers had not finished within {n}s (waiting at post-creation-handlers: resolving) — answering '{value}'memexmemex-portal-deployment-6749fbfc59-hdlgzAdmin/_LogIncident/31f12aedfc4bbbc8What triage wrote about this fingerprint
What is failing
When the portal records its boot-activity node (
Admin/PlatformVersion/_Activity/startup-*) during startup, the create request is answered with an unknown outcome: the node itself is written, but the create pipeline's post-creation handlers — still in the resolving phase — have not completed within the 30s budget. This is the platform's own startup bookkeeping write, on a single pod.Probable cause — medium confidence
Boot-time contention in the resolving phase of post-creation handling. The same hour the fleet logged heavy silo churn (multiple
Orleans.Runtime.SiloUnavailableExceptionroll-churn incidents on the memex namespaces around 03:05–03:54 UTC), so the resolving phase plausibly waited on a busy or restarting silo during portal boot. The write itself succeeded — this is a late completion signal, not a lost or rolled-back write. Cause is not established from one sample; if resolving regularly stalls >30s at boot there may be a real bottleneck worth naming.Impact
Single occurrence on a single pod; no user-visible failure and no data loss. The risk this exposes is a caller treating the unknown outcome as failure and re-creating the activity node — exactly the retry-after-timeout hazard the unknown-outcome contract (shipped 2026-09-09, see Create timeouts report an unknown outcome) was designed to flag.
Where to look
MeshWeaver.Mesh.CreateNode, stagepost-creation-handlers: resolving— and what that phase resolves at boot.[PlatformStartup]writes toAdmin/PlatformVersion/_Activity/startup-*), which issues this create during the boot sequence.Still occurring: 1 more since the last update (1 total).
memex-portal-deployment-6749fbfc59-hdlgzRecent log lines
systemorph-com commentedon Oct 11, 2026
Still occurring: 4 more since the last update (5 total).
memex-portal-deployment-6749fbfc59-hdlgzRecent log lines
rbuergi commentedon Oct 11, 2026
2026-10-11: the dump is read. The wait is a lock on the mesh's root container, held by one thread whose stack the analysis cut. #6490 makes the next read show it.
Ops/Actions/analyzedump-memex-cloud-20261011-ltlwc-2on the control instance completed at 08:02Z (read-only,Ops/Dumps/analyzedump-memex-cloud-20261011-ltlwc-2). It readmemex-portal-deployment-5499f76b76-ltlwc.1791656185/coredump.1.1791656179, written 2026-10-10 18:16:20Z: the first process of the pod in the 10-10 21:17Z timeline. 91 managed threads, 86 distinct stacks, 40 shown, at most 25 frames each.What it establishes.
syncblklists two contended monitors. Sync block 2:MonitorHeld 43, which is one owner and 21 waiters, owner OS thread0x1e. Sync block 169:MonitorHeld 9, one owner and 4 waiters, owner OS thread0xf1.Monitor.EnterinsideAutofac.Core.Lifetime.LifetimeScope.CreateSharedInstance, the lock a container takes to build a shared instance. They are:MeshExtensions.BuildPostCreationHandlers→GetRequiredService<IEnumerable<INodePostCreationHandler>>(threads0x107,0x105,0xee). This is thepost-creation-handlers: resolvingstage the log names.MessageHubGrain.ResolveHubConfigurationObservable, oneMeshNodeStreamHandle.UpdateRemote, oneMeshNodeStreamCachedelivery-failure handler,ProviderCredentialSeed.RunOverunderStaticRepoImportSettled.MarkSettled.0x103,0xff,0xfd,0xf8,0xec,0xeb): forIGrainCallCancellationManagerSystemTarget, forIDhtGrainDirectory, andPooledResponseCodec<IndirectProbeResponse>, the answer to a membership probe. ASP.NET building its endpoint matcher (0xf9).0xf1owns sync block 169 and is itself blocked inCreateSharedInstance, resolving a constructor parameter (AutowiringParameter→BoundConstructor.Instantiate). It holds one container's lock and waits for another's.0x106isMembershipTableManager.KillMyselfLocally→Environment.FailFast. The silo read the membership table, found itself declared dead, and ended the process. That is the 18:16:19Zcreatedump.So the six creates did not wait on a handler or on a module's proxy. They waited on the root container's shared-instance lock, with the rest of the silo. A silo that cannot create the codec for a probe response cannot answer its probes, which is how this pod came to be evicted. That ties this issue to the evictions on #6432 by a reading for this one pod; the other two pods' dumps (
…8c87bbfc-gvt4n,…85587f8869-5j9gx) are on the volume and were not read.What it does not establish: what thread
0x1eis doing. It owns the lock all 21 wait for, and its stack is not among the 40 shown. The analysis kept the largest groups and this thread's stack is its own.An inference, not a reading. Sync block 169 has four waiters and its owner waits on the root lock. If
0x1eis one of those four, this is a lock-order inversion between two containers: one thread holds the root container's lock and resolves into a module's container, another holds that module container's lock and resolves into the root. Since #6127 each module has a container of its own; it reaches the root throughModuleFallbackSourcewhile it may hold its own lock, and the root reaches it throughModuleContexts.ResolveModuleService(ModuleServiceForwarding, theCurrentroute) from wherever the root resolves, which can be inside a shared instance's construction. The timing fits (first wedges 10-09, #6127 merged 10-05) and so does the repro in #6455, which parks a module singleton's construction and gets the production line. The dump as read neither confirms nor refutes it.What settles it. #6490 changes the analysis so that a thread
syncblknames as a monitor's owner is a group of its own, sorted first, kept at four times the frame cap, and labelled with its waiters. Once the operator runs that script, filing the same action again ({ "requestedAction": "AnalyzeDump", "dumpPod": "memex-portal-deployment-5499f76b76-ltlwc" }onDeployments/memex-cloud) shows the stack of0x1e. If it is inside a module container'sCreateSharedInstance, the inversion is confirmed and the fix is to keep the root from resolving into a module container while it holds its own lock. If it is anything else, that stack names it.Recurrence. Last seen 2026-10-11 03:58:02Z on
memexpod…6749fbfc59-hdlgz, with(waiting at post-creation-handlers: resolving), which is this same lock seen from the create. Nothing was changed on any deployment.rbuergi commentedon Oct 11, 2026
The owner of the root lock is now read. Details are on #6432, from
Ops/Actions/analyzedump-memex-cloud-20261011-ltlwc-3on control.The creates parked at
post-creation-handlers: resolvingwait on the root container's lock. That lock is held by thread0x1e, which is building the scopedPortalApplicationin the root on behalf of the WhatsApp module.PortalApplication's constructor waits for the mesh hub scope's lock, and a grain activation holds that lock while it waits for the root's.This is not a module container under construction. The #6455 repro reproduces a related mechanism, not this owner.
Fix: #6536. Module scopes now resolve root registrations in a root child scope of their own, so a scoped service is never built under the root lock. This issue closes on a post-roll reading: no
post-creation-handlers: resolvingline after a boot on an image that contains #6536.systemorph-com commentedon Oct 11, 2026
Still occurring: 1 more since the last update (6 total).
memex-portal-deployment-6749fbfc59-hdlgz,memex-portal-deployment-5b769df8cb-89wxbRecent log lines
fix(modules): a module scope resolves root services in a root child s…
systemorph-com commentedon Oct 12, 2026
Still occurring: 2 more since the last update (8 total).
memex-portal-deployment-6749fbfc59-hdlgz,memex-portal-deployment-5b769df8cb-89wxbRecent log lines
rbuergi commentedon Oct 13, 2026
Closing: the closing reading from 2026-10-11 has now been taken. The condition was no
post-creation-handlers: resolvingstall after a boot on an image that contains #6536.ec7763883b, read from/api/version2026-10-13 ~14:55Z).Ops/Actions/wmlb-6391-memex-postcreate-24hon control). The query was{namespace="memex"} |~ "(?i)(post-creation handlers had not finished)|(\[PlatformStartup\])"over 24 h (2026-10-12 14:57Z to 10-13 14:57Z), and the read was not cut. It returned 97 lines. All 97 are[PlatformStartup]lines: 32 boots on images3.1.10648to3.1.10681, each recording its boot activity underAdmin/PlatformVersion/_Activity. None is apost-creation handlers had not finishedline. The boots are the positive control, since each one issues the very create this issue was about.Ops/Actions/wmlb-6391-memexcloud-postcreate-24h). Over the same 24 h,post-creation handlers had not finished|no verdict arrivedreturned 0 lines, and the read was not cut.Before the fix, the same site logged 8 occurrences across 2 boots on 10-11.