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

Steward PR-review intake aborts: ThreadNames.Prepared calls MeshWeaver.AI.ThreadPreparation.set_Group which the loaded core build does not have

Closed
  • Is something wrong?
#6,102 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
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend, devops

Research direction

Start by reading ThreadNames.Prepared and PullRequestIntake.StartThread in Hosting/Deployment/Source/PullRequestIntake.cs, then inspect MeshWeaver.AI.ThreadPreparation and the core and Hosting/Plugins assemblies loaded in the memex portal image. Verify whether the deployed assemblies come from a consistent build and whether the loaded core exposes the Group setter; done when the intake no longer fails with MissingMethodException and the deployment’s assembly versions are consistent.

Written by the indexing model from the issue text.

Description

bug sev:M

What is failing

The Steward's automated pull-request review never starts. PullRequestIntake.StartThread dies composing the review thread's name: ThreadNames.ReviewPrepared → ThreadNames.Prepared(group, name, description) sets MeshWeaver.AI.ThreadPreparation.Group, and throws System.MissingMethodException because the MeshWeaver.AI assembly loaded in the memex portal does not contain that setter. The review of MeshWeaver.Plugins#2795 at head d0da417 was left un-started (the sweep re-kicks it later).

Probable cause

Assembly version skew inside the memex portal deployment — high confidence. A MissingMethodException is a compile-time-vs-runtime mismatch: the Hosting code calling ThreadNames.Prepared was built against a core MeshWeaver.AI that exposes ThreadPreparation.set_Group(string), but the deployment loads a core build where it is absent. The calling code is not hypothetical — the PR the review was starting for (#2795, "fix(babysitter): fixer ladder …") is itself the change that introduces the call: its diff adds ThreadNames.Prepared(ThreadGroups.PrWork, threadName) at the StartThread site in Hosting/Deployment/Source/PullRequestIntake.cs, and its body states that thread categories are set through ThreadPreparation, with the Threads-app group support arriving in a separate PR. So the running Hosting build assumes a newer core seam than the portal's MeshWeaver.AI provides — either the Plugins build was compiled against a newer core than the one shipped in the image, or the deployment mixed builds from two source trees.

This is the same defect class as #6067 (filed 2026-10-04 from incident 8ec5bbc4142edbf4: ThreadNames.Clean calling ThreadNodeType.FlattenMarkdown(string), absent from the loaded MeshWeaver.AI), itself a recurrence of #6007. It is a sibling, not a duplicate: different missing member (ThreadPreparation.set_Group vs ThreadNodeType.FlattenMarkdown), different call seam (ThreadNames.Prepared from ReviewPrepared in StartThread vs ThreadNames.Clean from Compose in StartReview), and a different log-site fold — but the underlying mixed-build condition is almost certainly one and the same, and the #6007/#6067 fix evidently did not cover this seam either.

Impact

One occurrence on one pod so far, but the failing path is the standard entry for every Steward PR-review intake on the affected deployment: while the skew persists, every review arriving there fails to start. It is internal automation with a working escape — the pull-request sweep re-kicks a head without an internal-review check run on its next run — so no user-facing data is at risk; the cost is delayed/absent automated reviews and wasted review rounds.

Where to look

  • ThreadNames.Prepared(String group, String name, String description) — the helper that sets ThreadPreparation.Group; the top frame of the failure.
  • PullRequestIntake.StartThread in Hosting/Deployment/Source/PullRequestIntake.cs — the changed call site ThreadNames.Prepared(ThreadGroups.PrWork, threadName), introduced by the PR being reviewed (Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2795).
  • MeshWeaver.AI.ThreadPreparation in core — confirm when the settable Group property landed, and whether the core build shipped in the memex portal image includes it.
  • The memex-portal-deployment-76dd69c7fc image: verify the core MeshWeaver.AI and the Hosting/Plugins assemblies come from one build — the same consistency check that #6007 and #6067 prompted.

Related: #6067 (same exception class, same namespace, adjacent call seam in the same intake path), #6007 (the original OpenAIReasoningEffortWire skew that named the mixed-build condition).

Evidence
Fingerprint 0e53546c0ce851b7
Category PlatformBuildInboxWatcher
Severity Error
Exception System.MissingMethodException
Top frame ThreadNames.Prepared(String group, String name, String description)
Namespace memex
Pods memex-portal-deployment-76dd69c7fc-xzsdl
Occurrences 1
First seen 2026-10-04 20:10:39Z
Last seen 2026-10-04 20:10:39Z
Routing not determined — no configured route matches the category PlatformBuildInboxWatcher. 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-04 20:10:39Z memex-portal-deployment-76dd69c7fc-xzsdl fail: PlatformBuildInboxWatcher[0]
      [Steward] review of Hosting/Triage/pull-request/systemorph-meshweaver-plugins-2795 at d0da417b48e50a7efedc9933cc0aa3a32f0b8fa4 NOT started — Method not found: 'Void MeshWeaver.AI.ThreadPreparation.set_Group(System.String)'.
      System.MissingMethodException: Method not found: 'Void MeshWeaver.AI.ThreadPreparation.set_Group(System.String)'.
         at ThreadNames.Prepared(String group, String name, String description)
         at ThreadNames.ReviewPrepared(String name, String itemPath)
         at PullRequestIntake.<>c__DisplayClass107_0.<StartThread>b__0(IObserver`1 observer)
         at System.Reactive.Linq.QueryLanguage.CreateWithDisposableObservable`1.SubscribeCore(IObserver`1 observer)
         at System.Reactive.ObservableBase`1.Subscribe(IObserver`1 observer)

Opened automatically from Admin/_LogIncident/0e53546c0ce851b7. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site abf407e16e531a98: 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.