Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Untracked-module gate parks leftover SocialMedia/SocialTests NodeType on memex; declined bundle for framework c003e001 disagrees with in-mesh source fingerprint

Open
  • Is something wrong?
#6,930 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
devops, infrastructure

Research direction

Start with NodeTypeCompilationHelpers.DispatchOrPark, IsModuleContent, and MeshWeaver.Graph.CompileWatcher, then compare the deployment with origin/main de55a6fdd1. Check occurrences across pod restarts, the framework c003e001 bundle registry, and SocialMedia/SocialTests fingerprint fields before checking duplicate issues #6857 and #3583. Done means identifying which candidate cause is supported and locating a failing reproduction or confirming that the existing containment is expected.

Written by the indexing model from the issue text.

Description

bug sev:L

Observed

The CompileWatcher (MeshWeaver.Graph.CompileWatcher) reported NodeType SocialMedia/SocialTests on the memex instance PARKED after a compile failure: the untracked-module gate (MeshWeaver#3583) refused the compile because partition SocialMedia tracks no source on this mesh, and a prebuilt bundle for framework c003e001/linux-x64 that names the type was DECLINED — its source fingerprint disagrees with the files this mesh holds. The node itself (v1730) carries compilationStatus Error with this same gate message, currentModuleVersion 1.1 (the partition root is a Store/Plugin for module MeshWeaver.Social), failedBuildInputs fw=c003e001;mod=cfebaadf182f1eb0…;src=11:fa3c603f67aca6f9, and no adoptedSourceFingerprint or buildProvenance on the record.

Where and when

A single containment event on one pod of the memex instance. The node's lastCompileStartedAt sits about fifteen seconds before the log line — a compile attempt (activation or release request) triggered the gate's refusal and the watcher parked the type. This is not a burst.

Impact

Contained to the type itself: further activations serve the cached error (the watcher's own note: "no retry storm"). The type is leftover in-mesh test content in a partition nothing syncs; no user-facing surface was observed to depend on it.

Known context — likely duplicate, read before working this ticket

  • MeshWeaver#6857 tracked this same type compiling and failing on every boot (167 occurrences as reported).
  • Feedback Feedback/_Submissions/fb-498dadb037da3964640e82384a9f80dd (rbuergi, filed roughly twenty minutes before this line) analysed the gate NOT firing for this type: IsModuleContent(def, offeredByBundle) in NodeTypeCompilationHelpers.DispatchOrPark (origin/main de55a6fdd1) returned false because the type never adopted a bundle and the instance's registry grant no longer covers SocialMedia, so no bundle was offered. This incident's line is that gate firing — the containment the feedback described as the intended behaviour. Whether a change for #6857 reached this pod between the feedback and this line was not established.
  • The partition's removal is the subject of an unapproved request: rbuergi/Requests/socialmedia-finish-retire-6624.

Not established

  • Why a bundle appears in the refusal. The log names a prebuilt bundle for framework c003e001 that was offered and DECLINED on fingerprint grounds; the feedback's reading, taken minutes earlier, was that no bundle is offered at all (registry grant no longer covers SocialMedia). Either the offer condition changed in those minutes, or the gate's DECLINED wording fires without a live offer. Not determined.
  • Whether this PARKED line repeats per pod boot, as the pre-gate compile failure did under #6857 — this fingerprint has a single occurrence so far.
  • Whether other untracked module content on this mesh now parks under the same classification.

Candidate causes and the reading that separates them

  1. A gate change for #6857 deployed, and the gate now classifies the type as module content. Predicts one PARKED line per pod boot and the end of #6857's compile-failure fingerprint. Reading: occurrences of this fingerprint across pod restarts, and the state of NodeTypeCompilationHelpers.DispatchOrPark on the deployed build.
  2. A prebuilt bundle for framework c003e001 is now offered for this type (registry grant restored or bundle rebaked) but its fingerprint disagrees with the in-mesh files. Predicts the same DECLINED wording on other SocialMedia types and a visible bundle entry. Reading: the platform's bundle registry for framework c003e001 naming SocialMedia/SocialTests, and its source fingerprint against the node's currentSourceFingerprint 4f6c1d648a718ddb.
  3. The line is the gate's designed containment of a known leftover state, not a new defect — the underlying condition is the one #6857 and the pending retire request already track. Reading: nothing further; a human closes this against those.

Where to look

  • NodeType SocialMedia/SocialTests — compilationError, failedBuildInputs, currentSourceFingerprint on the node.
  • Feedback/_Submissions/fb-498dadb037da3964640e82384a9f80dd — the gate analysis (IsModuleContent, NodeTypeCompilationHelpers.DispatchOrPark, origin/main de55a6fdd1).
  • rbuergi/Requests/socialmedia-finish-retire-6624 — the pending removal request for the leftover partition.
  • MeshWeaver#6857 and MeshWeaver#3583 — the per-boot compile-failure incident and the gate's own issue.
Evidence
Fingerprint d327ba1e66652229
Category MeshWeaver.Graph.CompileWatcher
Severity Error
Namespace memex
Pods memex-portal-deployment-76f7486bf4-hhj4d
Occurrences 1
First seen 2026-10-18 00:47:39Z
Last seen 2026-10-18 00:47:39Z
Routing not determined — no configured route matches the category MeshWeaver.Graph.CompileWatcher. 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-18 00:47:39Z memex-portal-deployment-76f7486bf4-hhj4d fail: MeshWeaver.Graph.CompileWatcher[0]
      NodeType 'SocialMedia/SocialTests' PARKED after compile failure — further activations serve the cached error without recompiling (failure contained, no retry storm). Error: Untracked module content: NodeType 'SocialMedia/SocialTests' is a module's content, but partition 'SocialMedia' tracks no source on this mesh (no configured sync source), and the prebuilt bundle for framework c003e001/linux-x64 names this type but was DECLINED: its source fingerprint disagrees with the files this mesh holds (either side may be the newer one), and nothing syncs those files. This mesh does not compile a module's content it does not track — a local build of an install's leftover copy would serve old code as if it were current. Fix: add a sync source for 'SocialMedia' (Partition Sync administration) and sync it, or publish/rebake the package for this framework identity; then request a release to retry (MeshWeaver#3583).

This log site's previous ticket, https://github.com/Systemorph/MeshWeaver/issues/1105, was closed about a different fingerprint, and this fault fired after that close. It is left closed: an occurrence of this fingerprint is no evidence that the fault it was closed for came back. This issue now tracks the log site, and later fingerprints of it fold in here.

Opened automatically from Admin/_LogIncident/d327ba1e66652229. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site d76293b28e133585: other fingerprints of this site fold in here as comments rather than opening tickets of their own.

Dominant language
C#
Stars
12
Forks
5
Avg merge
5h 55m
Merged PRs (30d)
968

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Systemorph/MeshWeaver

All issues in Systemorph/MeshWeaver

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.