MemberJunction / MemberJunction/MJ
mj install reports the codegen phase failed on a successful install: a timed-out AFTER command now resolves as failure, and the shipped config uses a 30s npm start as a boot probe
- Dominant language
- TSQL
- Stars
- 29
- Forks
- 6
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 323
Description
Found by LTS certification gate 4 (fresh-install matrix) for 6.1.1 on 2026-09-15, macOS leg. Tracking: #4475.
**A fresh `mj install` of 6.1.1 ends with "Installation failed. Failed phase(s): codegen" even though the install is complete and MJAPI boots.** The distribution `mj.config.cjs` (identical at v5.51.0, v6.1.0 and v6.1.1) runs `npm start` in `apps/MJAPI` as an AFTER command with `timeout: 30000`, as a boot probe. MJAPI booted to `Ready` in 18.9 seconds and was killed at 30 seconds as designed. In `@memberjunction/codegen-lib` 5.51.0, `runCommand.ts` resolved a timed-out command as `success: !bErrors`, so the probe counted as a pass unless the process had logged errors. Since #3804 (2026-08-27, first shipped in 6.1.0-edge.5) the timeout branch resolves `success: false` unconditionally (`runCommand.ts` around line 150 on v6.1.1), so the probe always fails, CodeGen reports the phase failed, the installer's own smoke phase never runs, and the user is told the install failed.
On 6.1.0 this was masked by #4477: the phase failed earlier on the missing `entity_subclasses.ts`. With that fixed in 6.1.1, this is the next thing a fresh install hits.
**Evidence.** Registry-true install of 6.1.1 on a fresh SQL Server 2022 database: every phase through migrate passed, CodeGen emitted all artifacts (388 entities, `entity_subclasses.ts` and the Angular generated-forms module present, GeneratedEntities builds), MJAPI answered HTTP 401 to an unauthenticated GraphQL POST, Explorer served its app shell, and `mj sync push` of the tag's metadata was a clean no-op across 89 directories. The only failure is the installer's verdict. Full report is a comment on #4475.
**Fix options, either is one line.** Restore the 5.51 semantics in `runCommand.ts` (a timeout is not a failure unless the process logged errors; the config uses timeouts deliberately as probes), or change the shipped AFTER command so the probe exits on its own instead of relying on the kill. The first is the safer one because it also covers user configs that copied the pattern.
**Line impact.** Code-only, backport-eligible. Not a showstopper under 14.1 (the product runs; the installer's verdict is wrong and its own smoke test is skipped), so it should ride the first post-cert line patch rather than force a second respin, unless the cert owner rules otherwise. It is the same shape as the 5.51 installer readiness-regex false negative, which was recorded and not blocking.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Research direction
Start in @memberjunction/codegen-lib's runCommand.ts around the timeout branch near line 150, then review how the shipped mj.config.cjs uses the 30-second npm start probe. Verify the timeout result matches the intended probe semantics without masking logged errors, and confirm a fresh mj install reports success while MJAPI reaches Ready and the generated artifacts are present.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, typescript
- Domain
- build-system, cli
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100