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

Provisioning of the deliberately-removed ReinsuranceDemo package re-attempted on memex and refused at the phase-2 upstream-module check

Open
  • Is something wrong?
#7,051 0 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
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
observability-sre

Research direction

Start with the provision-plan runner logged under category ProvisionPlan, then inspect the removal history in rbuergi/Requests/remove-reinsurance-and-education. On the memex portal, check Plugins/ReinsuranceDemo, nearby Plugins/* records, package.provision activities around 2026-10-21 19:54 UTC, and any surviving GitSync source. Determine which candidate trigger initiated the attempts and whether it recurs after a pod roll.

Written by the indexing model from the issue text.

Description

bug sev:L

Observed

A package-provision plan for the package ReinsuranceDemo on the memex portal was refused at its phase 2/8 pre-flight check, "Check declared upstream modules": the plan declared Claims, Ifrs17, Reinsurance, SST and Underwriting as upstream modules, none of them is installed on the mesh, and the plan aborted before writing anything ("Nothing was installed"). This is the gate working as designed — it refuses to install a package whose nodes use NodeTypes from modules that are not registered, because such a node cannot activate and every read of it costs the caller the full hub-activation timeout.

Where and when

A burst of three identical attempts within ~12 seconds on a single pod of the memex portal deployment. The target space and all five named upstream modules had been deliberately removed from this portal six weeks earlier: the approved operation rbuergi/Requests/remove-reinsurance-and-education (executed 2026-09-06, reason: "Systemorph's internal portal does not use the reinsurance or education modules") deleted ReinsuranceDemo, Reinsurance, Claims, Underwriting, Ifrs17, SST, SwissSolvencyTest and six further reinsurance spaces, removing each Plugins/{id} install record BEFORE the partition precisely so that "module discovery cannot re-provision the Space". So the interesting question is not the refusal — it is what re-initiated provisioning for a package that was intentionally retired from this mesh.

Impact

No data was written and no existing content was touched; the refusal is protective. The ReinsuranceDemo space is absent, which matches the portal's stated intent. The only visible effect is the error burst itself — unless the trigger is a recurring sweep, in which case this fires on every activation/boot.

Not established

  • What initiated the provision plan on 2026-10-21. The memex portal's own records (its Plugins/ install records, its provision activities, its GitSync sources) are not readable from the instance this incident was filed on, so the trigger could not be identified.
  • Whether it still recurs, and whether it fires on every pod boot/activation or was a one-off burst.
  • Whether an install record or entitlement for ReinsuranceDemo reappeared on memex between 2026-09-06 and 2026-10-21 (e.g. a GitSync re-import, a publication wave, or a manual re-add), or whether some discovery path references the removed package without one.
  • Whether other deliberately-removed packages from the same operation are also being re-attempted — only this one is on this incident.

Candidate causes and the reading that separates them

  1. A re-introduced install record or store entry. Something re-created Plugins/ReinsuranceDemo (or an equivalent entitlement/catalog entry) on memex, and module discovery or a store "Get" then attempted provisioning. Predicts the record is present on the portal now. Discriminating reading: get Plugins/ReinsuranceDemo (and the Plugins partition listing) on the memex portal, plus the store cover/catalog entry for ReinsuranceDemo.
  2. A one-off operator or user action. Someone deliberately tried to re-install ReinsuranceDemo without provisioning the five upstream leaves first (exactly the misuse the phase-2 text warns about). Predicts a governed package.provision activity node naming the requester, at the burst's timestamps. Discriminating reading: the provision activity / InstanceAction nodes around 2026-10-21 19:54 UTC on the portal, and the plan's provenance (via).
  3. A discovery/sweep path that still references the removed package. A scheduled discovery or entitlement-driven sweep (analogous to the StandardPacks.EnsureForAllUsers loop documented for install verifies) retries ReinsuranceDemo on every activation because some residual reference — an entitlement, a chart, a synced file — survived the removal. Predicts recurrence at pod-boot/activation cadence across pods. Discriminating reading: whether the burst repeats after the next pod roll, and whether the timing lines up with activation events rather than human action.

Where to look

  • The provision-plan runner logged under category ProvisionPlan, phase 2/8 "Check declared upstream modules" — the refusing component.
  • rbuergi/Requests/remove-reinsurance-and-education — the 2026-09-06 removal, its reason and its delete order (install record before partition), which defines what "absent" should mean on this mesh.
  • On the memex portal: Plugins/ReinsuranceDemo and the neighbouring Plugins/* records, the package.provision activities around the burst, and ReinsuranceDemo's GitSync source if any survived.
Evidence
Fingerprint 3ea5f7e76b292e0a
Category ProvisionPlan
Severity Error
Namespace memex
Pods memex-portal-deployment-699f8dd49c-4jm8w
Occurrences 3
First seen 2026-10-21 19:54:25Z
Last seen 2026-10-21 19:54:36Z
Routing not determined — no configured route matches the category ProvisionPlan. 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-21 19:54:25Z memex-portal-deployment-699f8dd49c-4jm8w fail: ProvisionPlan[0]
      [ProvisionPlan] 'ReinsuranceDemo' FAILED in phase 2/8 'Check declared upstream modules': 'ReinsuranceDemo' requires modules 'Claims', 'Ifrs17', 'Reinsurance', 'SST', 'Underwriting' to be installed first — its nodes use NodeTypes from those modules, and a node whose type is not registered cannot activate (every read of it costs the caller the full 60s hub-activation timeout). Nothing was installed. Provision them on this mesh first, leaves first — each through its own governed package.provision activity — then retry this one.
2026-10-21 19:54:33Z memex-portal-deployment-699f8dd49c-4jm8w fail: ProvisionPlan[0]
      [ProvisionPlan] 'ReinsuranceDemo' FAILED in phase 2/8 'Check declared upstream modules': 'ReinsuranceDemo' requires modules 'Claims', 'Ifrs17', 'Reinsurance', 'SST', 'Underwriting' to be installed first — its nodes use NodeTypes from those modules, and a node whose type is not registered cannot activate (every read of it costs the caller the full 60s hub-activation timeout). Nothing was installed. Provision them on this mesh first, leaves first — each through its own governed package.provision activity — then retry this one.
2026-10-21 19:54:36Z memex-portal-deployment-699f8dd49c-4jm8w fail: ProvisionPlan[0]
      [ProvisionPlan] 'ReinsuranceDemo' FAILED in phase 2/8 'Check declared upstream modules': 'ReinsuranceDemo' requires modules 'Claims', 'Ifrs17', 'Reinsurance', 'SST', 'Underwriting' to be installed first — its nodes use NodeTypes from those modules, and a node whose type is not registered cannot activate (every read of it costs the caller the full 60s hub-activation timeout). Nothing was installed. Provision them on this mesh first, leaves first — each through its own governed package.provision activity — then retry this one.

This log site's previous ticket, https://github.com/Systemorph/MeshWeaver/issues/6896, 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/3ea5f7e76b292e0a. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 8aa2f9ea523cf69c: 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
6h
Merged PRs (30d)
967

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.