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

Apps install without their modules: the registry lists package versions whose module generation it cannot serve

Open
  • Is something wrong?
#7,181 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend, infrastructure

Research direction

Start with src/MeshWeaver.PluginCatalog/ModuleBundleSource.cs, especially CollectVersion, and trace how package versions are listed and module generations are selected. Compare the behavior with issue #7041 and inspect the install-defaults pass mentioned here. Done means a package is not offered or reported installed until every declared module is available, with the issue's fallback route as an alternative.

Written by the indexing model from the issue text.

Description

bug sev:H

Requirement: when a package is installed, its declared runtime module must arrive with it. If the module can't arrive, the package must not install as if it were complete.

What happens: the plugin registry (memex.meshweaver.cloud) serves a package version whose declared module it cannot supply. #7041 made this a stated miss rather than a silent empty bundle, but the cause remains. Read on 2026-10-25 from /health → bundle_adoption:

Instance (platform) Adoption attempts Misses Module the registry declined
memex.systemorph.com (c4e0ecb1b6) 40 14 MeshWeaver.AI.Acp 1.0.200/1.0.201, MeshWeaver.AI.Anthropic 1.2.148, MeshWeaver.AI.AppleIntelligence 1.1.148, MeshWeaver.Observability 1.8.97, MeshWeaver.Notifications.Channels 1.1.250, MeshWeaver.Mail.MicrosoftGraph 1.22.3, MeshWeaver.Teams 1.2.51, MeshWeaver.Blazor.Chat 1.7.65; also Antigravity and Cursor (the bundle carried no assemblies, with no reason given)
build.meshweaver.cloud (62c1d51225) 3 2 MeshWeaver.AI 1.38.4 and 1.38.5 (two replicas, two versions); LinkedIn (no reason given)

Every row reads module '<name>': not served — the package declares this module but this registry cannot serve it at <v>: module '<name>' has no retained generation at version <v> (src/MeshWeaver.PluginCatalog/ModuleBundleSource.cs, CollectVersion).

What this means: as #7041 put it, "the package record is ahead of the module's own publish (record at N+1, shelf holds N)". Package versions are listed, and installed by every instance's install-defaults pass, before or without the module generation they declare. On an instance that already holds an older generation locally, the app keeps running on stale code. On a fresh instance, such as build after its reset to the dev role, nothing holds the module, so the app's tile shows up with no working module behind it.

What a fix has to guarantee: a package version is only listed, or only offered to an installer, once every module it declares has been published for that version. Two possible routes: publish package and module atomically, or let the registry fall back to the newest retained, compatible module generation and say so in the bundle. Also, as a check, an install-defaults pass should never report success on an instance where a declared module failed to arrive.

Not established:

  • The registry shelf contents. Reading them needs a registry key; I read only the consumers' /health.
  • Whether the misses on memex.systemorph.com actually break features there. Older module generations exist under /data/modules, so they may still be serving stale code.
  • Whether Antigravity, Cursor and LinkedIn (no reason given) follow the same path. #7041's "Not established" already notes the nodes-only LastCompiledVersion filter.
  • Whether ClaudeCode (MeshWeaver.AI.ClaudeCode) has arrived on build. It wasn't among build's 3 attempts at the time of reading.

Refs #7041.

🤖 Generated with Claude Code

Dominant language
C#
Stars
12
Forks
5
Avg merge
6h 37m
Merged PRs (30d)
929

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.