diff --git a/.squad/agents/sam/history.md b/.squad/agents/sam/history.md index 95ec38ed..43d55268 100644 --- a/.squad/agents/sam/history.md +++ b/.squad/agents/sam/history.md @@ -37,15 +37,22 @@ None. No Web production code changes required. ### Recommendation for Boromir -Pin the MongoDB container image to a stable tag in AppHost.cs: +Pin AppHost to MongoDB 7 and use a fresh MongoDB 7 data volume in AppHost.cs. +MongoDB 8.x is the affected family in this environment because the container +expects AVX-capable CPUs and crashes before the app can connect. ```csharp var mongo = builder.AddMongoDB("mongodb") - .WithImageTag("8.0") // pin away from 8.2 which SIGSEGVs - .WithDataVolume("mongo-data") + .WithImageTag("7") + .WithDataVolume("mongo-data-v7") .WithMongoExpress(); ``` +If a machine has already started MongoDB 8.x with the legacy `mongo-data` +volume, do not reuse that volume for MongoDB 7. The old volume can retain +MongoDB 8 feature compatibility version metadata, and MongoDB 7 can then exit +with code 62 during startup. + --- ## 2026-05-15 — Issue #339: Category Backend (branch squad/339-category-backend) @@ -105,9 +112,18 @@ Some test and skill files in the working tree (aragorn/boromir history files, a Adding `Guid? CategoryId` with explicit `AssignCategory`/`RemoveCategory` domain methods preserves existing behavior (tests pass with `null`) while giving Legolas and the UI a clean optional-becomes-required upgrade path without a breaking API change. -### mongo:8.2 (Aspire.Hosting.MongoDB 13.3.3 default) causes exit 139 (SIGSEGV) +### MongoDB 8.x crashes here; the safe fix is MongoDB 7 with a fresh v7 volume + +When diagnosing MongoDB container crashes under Aspire, check the image tag +first. In this environment, the MongoDB 8.x family is the crashing family +because those images require AVX-capable CPUs. The safe fix is to pin AppHost +with `.WithImageTag("7")` and use `.WithDataVolume("mongo-data-v7")`. -When diagnosing MongoDB container crashes under Aspire, check the image tag first. Exit code 139 is SIGSEGV — an image-level crash, not an application wiring defect. The fix is to pin the container image with `.WithImageTag("8.0")` in AppHost. Web timeout logs are downstream symptoms of the container crash and should not be mistaken for wiring bugs. +Do not reuse the legacy `mongo-data` volume after a MongoDB 8.x run. That +volume can retain MongoDB 8 feature compatibility version metadata, which can +make MongoDB 7 exit with code 62 during startup. Web timeout logs remain +as downstream symptoms of the container crash and should not be mistaken for +wiring bugs. --- @@ -529,35 +545,22 @@ When upsert (`ReplaceOneAsync + IsUpsert=true`) is the behavior, log strings mus --- -## 🔴 CORRECTION: Issue #345 MongoDB Container Crash Fix (2026-05-17) - -**By:** Scribe (correction appended) -**Referenced:** Lines 44–45 (recommendation code snippet) and Line 110 (learning item) contained incomplete/incorrect guidance. - -### What Was Wrong - -Sam's original investigation correctly identified the root cause (MongoDB 8.x SIGSEGV) but the **recommendation and learning item were incomplete:** - -- **Line 44–45:** Recommended pinning to `mongo:8.0` and keeping `mongo-data` volume -- **Line 110:** Stated the fix is `.WithImageTag("8.0")` - -### What Actually Happened (Implementation) - -Boromir's infrastructure fix (issue #345) pinned to **`mongo:7`** (not `8.0`) **and renamed the volume to `mongo-data-v7`** (not keeping `mongo-data`). +## Issue #345 History Correction (2026-05-17) -**Why this was necessary:** +**By:** Scribe +**Reason:** Reviewer lockout required an independent correction to Sam's history +artifact, so the stale guidance was revised in place instead of being left as an +active recommendation. -1. **Image tag:** MongoDB 8.x (including 8.0) still requires AVX CPU instructions. Pinning to `mongo:7` LTS (which does NOT require AVX) is the stable solution. -2. **Volume rename:** When the first attempt used `mongo:7` but the old `mongo-data` volume remained, MongoDB 7 exited with code 62: `Wrong mongod version — featureCompatibilityVersion "8.2"`. MongoDB refuses to open data files from a newer major version. Renaming to `mongo-data-v7` gave MongoDB 7 a fresh, compatible volume. +### Canonical Outcome -### Accepted Final Fix - -```csharp -var mongo = builder.AddMongoDB("mongodb") - .WithImageTag("7") // pin to LTS with no AVX requirement - .WithDataVolume("mongo-data-v7") // version-suffixed volume to avoid featureCompatibilityVersion mismatch - .WithMongoExpress(); -``` +- Use MongoDB 7 in AppHost for this fix path. +- Use `mongo-data-v7` for the persistent volume. +- Treat MongoDB 8.x as the affected family in this environment because those + images require AVX-capable CPUs and crash before the app can connect. +- Do not reuse the legacy `mongo-data` volume after a MongoDB 8.x run; it can + retain feature compatibility version metadata that makes MongoDB 7 exit with + code 62. ### Validation Results @@ -568,8 +571,7 @@ var mongo = builder.AddMongoDB("mongodb") ### Standing Rule (From Decision) -When MongoDB major version changes on an Aspire dev environment with a pre-existing persistent volume, suffix the volume name with `v{major}` (e.g., `mongo-data-v7`, `mongo-data-v8`). This prevents featureCompatibilityVersion mismatch crashes transparently. - -### Why Scribe Is Appending This - -Reviewer lockout: Sam authored the incorrect guidance, so Sam cannot revise their own history artifact. Scribe appends this correction to preserve accuracy and allow the PR to proceed. +When MongoDB major version changes on an Aspire dev environment with a +pre-existing persistent volume, suffix the volume name with `v{major}` (for +example, `mongo-data-v7`). This prevents feature compatibility version mismatch +crashes transparently.