MemberJunction / MemberJunction/MJ
Certification: MJ 6.1.0 (lts/6.1)
- Dominant language
- TSQL
- Stars
- 29
- Forks
- 6
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 323
Description
Tracking issue for certifying **MJ 6.1.0**, the candidate for the **6.1 LTS line**. Process: `plans/lts-process.md` section 6 (gates) and section 14.1 (blocker batching and the respin ratchet). Evidence lands on the scorecard at `certifications/6.1.0.md` (to be opened from `certifications/TEMPLATE.md`); this issue is the running log and the place to link findings.
| Field | Value |
|---|---|
| Candidate | **6.1.1** on `lts/6.1`, tag [`v6.1.1`](https://github.com/MemberJunction/MJ/releases/tag/v6.1.1), commit ce691db5 (respin of 6.1.0, published 2026-09-15 with the #4477 and #4483 fixes; batch closed 04:14 UTC) |
| npm | `@memberjunction/*@6.1.1` under dist-tag `lts-6.1` (`latest` stays 5.51.2 until sign-off) |
| Cut | 2026-09-14 from the tip of `next`, right after 6.1.0-edge.7 |
| Certification owner | @cadam11 |
| Target sign-off | week of 2026-09-21; hard backstop 2026-10-01 |
## Gates
| # | Gate | Owner | Status | Evidence |
|---|---|---|---|---|
| 1 | CI green on the candidate (unit, build, migrations, PG translation, CodeQL, peer ranges vs the era platform manifest) | CI | **6.1.1 pass** (2026-09-15); 6.1.0 pass | 6.1.1, all green on `lts/6.1` at ce691db5: [Unit Tests](https://github.com/MemberJunction/MJ/actions/runs/34929492391), [Build](https://github.com/MemberJunction/MJ/actions/runs/34929494280), [Test migrations](https://github.com/MemberJunction/MJ/actions/runs/34929495894), [PG migration validation](https://github.com/MemberJunction/MJ/actions/runs/34929498039), [CodeQL](https://github.com/MemberJunction/MJ/actions/runs/34929499653), [Release Validation Suite](https://github.com/MemberJunction/MJ/actions/runs/34929502785). 6.1.0 evidence: all six dispatched on `lts/6.1` 2026-09-14 and green: [Unit Tests](https://github.com/MemberJunction/MJ/actions/runs/34846109677), [Build](https://github.com/MemberJunction/MJ/actions/runs/34846112398), [Test migrations](https://github.com/MemberJunction/MJ/actions/runs/34846115250), [PG migration validation](https://github.com/MemberJunction/MJ/actions/runs/34846118088), [CodeQL](https://github.com/MemberJunction/MJ/actions/runs/34846120516), [Release Validation Suite](https://github.com/MemberJunction/MJ/actions/runs/34846125822). Cut base 8bc2f423 was green on `next` (unit shards 1 to 6, Build, ESM guard, CodeGen drift gate, CodeQL). Local on the `v6.1.0` checkout: `node ci/validate-release-lines.mjs` OK, `check:peer-deps` 317 manifests clean, `check:esm` OK. UI token/button and dependency checks are PR-triggered; their standing green on `next` through the freeze stands in, as for 5.51.0. |
| 2 | Deterministic integration tier against a dedicated fresh DB | CI | **6.1.1 pass** on the first run (2026-09-15); 6.1.0 pass with one recorded flake | 6.1.1: [run 34929501279](https://github.com/MemberJunction/MJ/actions/runs/34929501279), deterministic tier 70/77 passed, 7 skipped (mutation-gated and sidecar-gated bundles), zero failures. The run shows red only because the advisory CodeGen drift gate found `version.generated.ts` still at 6.1.0: the line release job does not commit the post-release generated file the way the Edge and cut paths do, a release-tooling gap, not a product defect. 6.1.0: three runs on `lts/6.1`: [run 1](https://github.com/MemberJunction/MJ/actions/runs/34846123089) failed on a timing cascade (see Findings), then [run 2](https://github.com/MemberJunction/MJ/actions/runs/34849395411) and [run 3](https://github.com/MemberJunction/MJ/actions/runs/34850849406) both 70/77 passed, 7 skipped (the mutation-gated and sidecar-gated bundles CI skips on `next` by design), zero failures. Two consecutive clean passes per the flake policy. The workflow provisions a fresh SQL Server container, migrates from scratch, runs `mj sync push --ci`, boots MJAPI and runs `pnpm run test:integration`, so it meets the dedicated-DB bar without a local run. |
| 3 | Full UX Regression Suite (AI-driven) against a fresh install of the candidate | Caeleb (cert owner accepts) | not started | Results packet to be attached to the scorecard. Flake policy: max 2 reruns, must pass clean twice in a row. |
| 4 | Fresh-install matrix: `mj install` of 6.1.0 on clean macOS and Windows; sample environments | @cadam11 (macOS locally, Windows on a temporary EC2), as for 5.51 | 6.1.0: macOS FAIL, Windows FAIL, both on #4477, sync-push assertion PASS on both. **6.1.1 macOS: PASS with recorded finding #4495** (2026-09-15, ruling: recorded): registry-true install of 6.1.1, 85 migrations, CodeGen emitted `entity_subclasses.ts` and the Angular module (#4477 confirmed fixed), MJAPI booted and answered 401, Explorer served the app shell, record create and view read passed in-process, sync push of the v6.1.1 archive metadata was a clean no-op (89 of 89 directories, 14,218 records). The installer itself still prints "Installation failed" because its `npm start` boot probe times out by design and the timeout now counts as failure, #4495; the installer smoke phase therefore did not run. Agent-run smoke: 401 from OpenAI, environmental (dead key). **6.1.1 Windows: PASS with recorded finding #4495** (2026-09-15): clean Windows Server 2022 EC2 with SQL Server 2022 Express, registry-true install of 6.1.1, 85 migrations, CodeGen emitted `entity_subclasses.ts`, the Explorer module and MJAPI `generated.ts` (#4477 confirmed fixed on Windows), MJAPI booted in 39s and answered 401, Explorer served the app shell with zero build errors, record create and view read passed in-process, sync push of the v6.1.1 archive metadata was a clean no-op (89 of 89, 14,218 records). Installer verdict "failed, phase codegen" is #4495 reproduced; on Windows MJAPI takes 39s to boot so the 30s probe kills it before ready, same outcome. The 15-minute pnpm cap killed the cold run once again (#4478 item), checkpoint resume completed it. Agent-run smoke 401 from OpenAI, environmental. **Gate 4 result on 6.1.1: PASS with recorded findings, both platforms.** | macOS: registry-true install of 6.1.0 on a fresh SQL Server 2022 container. Preflight, 85 migrations (baseline 202607091514) and the DB side of CodeGen completed; the TS side wrote no `entity_subclasses.ts` and no Angular module, so MJAPI and Explorer cannot boot. Cert-blocker #4477. The `mj sync push` no-op assertion itself **passed**: 89 of 89 directories, 14,218 records, no changes, from the v6.1.0 source archive metadata because the distribution ships no metadata folder. Installer findings in #4478. Full report is the first comment on this issue. Windows: registry-true install on a clean Windows Server 2022 EC2 with SQL Server 2022 Express reproduces the same signature exactly (388 entities, no `entity_subclasses.ts`, TS2307, MJAPI cannot find the module). Migrations clean: 85 files, flyway history 86 of 86. Sync push from the v6.1.0 archive metadata: 89 of 89 directories no changes, 14,218 unchanged, 0 errors, 25s. Record create and view read passed through `mj ai` in-process with a side-by-side config carrying `dbDatabase` (see #4478). Agent run reached OpenAI and got 401, an invalid key on the test host, environmental. Fix in #4479; gate 4 reruns on 6.1.1. Both full reports are comments on this issue. |
| 5 | Upgrade matrix: CDP, Skip, Izzy, MJC stage on the candidate, plus AIDP Next stage | Soham (CDP), Caeleb and Jordan (Skip), Ian (Izzy), Madhav (MJC), AIDP Next owner to be named | CDP: FAIL on 6.1.0 (#4483, fixed in 6.1.1); **CDP: FAIL on 6.1.1** (2026-09-15) on #4503, Metadata_Sync migrations collide with rows `mj sync push` already created; **MJC: PASS on 6.1.1** (reported 2026-09-15); Skip, Izzy pending; AIDP Next owner to be named | Each owner reports pass or fail plus issues within 2 business days of the request. |
| 6 | Human hammering on core flows | @cadam11 and crew | not started | Session notes and hours logged. |
| 7 | Zero open cert-blockers | process | **2 open: #4477, #4483** | [`label:cert-blocker is:open`](https://github.com/MemberJunction/MJ/issues?q=is%3Aissue+is%3Aopen+label%3Acert-blocker) |
| 8 | Sign-off | @cadam11 | pending | `release-lines.json` PR: status certified, certifiedBuild, certifiedDate, supportEnds, scorecard path; `latest` flip from the certified tag's checkout; GitHub Release marked latest; 5.51 moves to maintenance in the same PR. |
## Filing a find
Open an issue and label it `cert-blocker` only if it would fail a gate or the scorecard could not honestly carry it as a known issue. Everything else is recorded in the findings table below and ships in the line's first post-cert patch or in 6.2.
Fixes land on `next` first. Put the `backport lts/6.1` label on the merged PR and the bot opens the cherry-pick to `lts/6.1`. Code-only and data-only metadata fixes qualify; anything with DDL stays on `next` and ships in 6.2.
Blockers batch into at most one respin (6.1.1) before the gate 5 soak begins. The batch close date will be announced in the dev channel and recorded here. From soak start the respin bar is showstopper only. Automated gates 1 to 3 rerun wholesale on a respin; soak evidence carries across a small delta.
## Findings
| Issue | Severity | Disposition |
|---|---|---|
| #4477 CodeGen emits no `entity_subclasses.ts` or Angular generated module when there are zero non-core entities; every fresh `mj install` of 6.1.0 fails to boot MJAPI and Explorer. Regression from #3804, first shipped in 6.1.0-edge.5. | **cert-blocker** | Forward fix on `next`, `backport lts/6.1`, goes in the 6.1.1 batch. Gate 4 reruns on 6.1.1. |
| #4483 Upgrade from 5.51.2 fails in the legacy retirement migration on any database that used Reports: `spDeleteEntityWithCoreDependencies` misses `ResourceType.CategoryEntityID` and ~50 other inbound FKs, and has no `XACT_ABORT`. Found on CDP stage; CDP production has the same row. | **cert-blocker** | Data-only pre-clean migration versioned before the retirement one, backported to lts/6.1 for the 6.1.1 batch; proc hardening on `next`. Gate 5 CDP reruns on 6.1.1. |
| #4503 Upgrade to 6.1.1 fails in the Metadata_Sync migrations on databases where `mj sync push` ran before migrating: the emitter records every fixed-GUID create as an unguarded `spCreate`, and 190 of them collide with metadata-shipped primary keys across 8 files. Fresh installs, CI, and MJC stage are clean; CDP stage and production are affected and have no ordering workaround. | **ruling pending** (cert owner; hold for Skip and Izzy reports) | Emitter emits create-or-update (Layer 1, `next`); regenerate the 8 shipped files with guards in place (Layer 2a, no repair needed since the runner never validates checksums); backport to `lts/6.1` as a line patch if ruled in; add the migrate, push, migrate regression test. |
| #4495 `mj install` of 6.1.1 reports the codegen phase failed on a successful install: a timed-out AFTER command resolves as failure since #3804, and the shipped config uses a 30s `npm start` as a boot probe. Masked on 6.1.0 by #4477. | **recorded, does not block** (cert owner ruling 2026-09-15) | One-line fix in codegen-lib or the shipped config; code-only, backport-eligible; rides the first post-cert line patch. |
| #4478 Installer findings: preflight pnpm false negative when `--dir` is new, relative `--dir` breaks migrate, no shipped `metadata/`, `mj ai` needs `dbDatabase` in `mj.config.cjs`. | recorded, does not block | Code-only items are backport-eligible if fixed; the metadata decision is a product call. |
| #4486 A failed metadata dataset fetch replaces the metadata cache with an empty one. Reproduced on `next` twice more on 2026-09-14 evening (runs 34893391381, 34898029723), so no longer a one-off. `GetDatasetByName` in GenericDatabaseProvider catches the batch error, logs it and falls through with empty results; every later `EntityByName` then fails with "not found in metadata". Seen in gate 2 run 1 (70 cascading failures from one connection drop). | recorded, blocker ruling pending (cert owner) | Forward fix on `next`: keep the previous cache on a failed refresh and surface the error. Backport-eligible, code-only. Until fixed, gate 2 evidence needs reruns. |
| A malformed statement on the pool closes the connection for other in-flight requests ("Connection closed before request completed" on the metadata fetch immediately after the runquery-cache bundle's deliberate bad SQL). Timing-dependent; not reproduced in runs 2 and 3 nor in the last week of `next` runs. | recorded, does not block (cert owner to confirm) | Owner of the SQL Server provider to assess alongside the queue-drain change (#4448). |
## Known process notes from the cut
- The cut run stopped after the npm publish at the tag step (shell glob in `git add`, fixed in #4472). The remaining steps were finished by hand from a local reproduction; tag, branch, ledger and pre-mode re-entry are all verified against the run's checkout SHA.
- The ledger's `candidateDate` still reads 2026-09-11 (the original plan). The field is immutable in the validator once set; a validator relaxation is needed to correct it.
- Release notes for 6.1.0: #4471, opened by hand because the `backport lts/6.1` label did not exist when the notes workflow tried to open it. The label exists now.
Contributor guide
Assessment
This issue has not been assessed yet.