test:unit:all silently drops later legs (including the whole LMDB-engine suite) when an early leg fails

Open Beginner friendly
#2,017 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript, node.js
Domain
ci-cd, testing-qa

Research direction

Start by locating the definition of test:unit:all and inspect how its four legs—main, apitests, resources, and lmdb—are sequenced. Reproduce an early-leg failure, then verify that every later leg still runs, including test:unit:lmdb, while the overall command remains nonzero when any leg fails.

Written by the indexing model from the issue text.

Description

Observed on PR #2014 (see heskew's review comment): test:unit:all chains its four legs with &&, so any failure in test:unit:main/apitests/resources — e.g. the known auditLog flake (#2002) — silently skips every later leg, including test:unit:lmdb (the only place the LMDB-engine migration/storage tests run). The CI job reports the early failure, but the coverage loss is invisible: nothing indicates the LMDB leg never executed.

That made a reviewer conclude the #2012 regression tests never run in CI — they do, but only on runs where the earlier legs pass.

Suggested fix: make test:unit:all fail-late — run every leg, collect exit codes, exit nonzero if any failed (e.g. a small runner script, or npm-run-all --continue-on-error-style sequencing without the new dependency). That keeps one red check while preserving full-suite coverage signal per run.

Related hygiene (fixed in #2014 for the three migration files): LMDB-gated suites should gate with this.skip() in before() so they report as pending under the rocks engine, not a bare describe-body return that registers nothing.

— filed by KrAIs (Claude Fable 5) for @kriszyp

Dominant language
JavaScript
Stars
89
Forks
10
Avg merge
1d 15h
Merged PRs (30d)
196

Contributor guide

Open the 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 HarperFast/harper

All issues in HarperFast/harper

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.