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

Phase 2: publish typed failures on total failure, and guard zero discovery

Open
  • Is something wrong?
#1,802 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
30/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
data

Research direction

Start in scripts/zarr/generate_zarr.py at the branch that handles attempted recordings with no converted entries, then at the zero-discovery path that publishes an index and runs the --clean removal step. First write a fixture-tree test that reproduces a zero-discovery run over a dataset with prior stores, and confirm whether it removes them. Done when total-failure runs write index.json with failures[] populated, zero-discovery runs publish a typed no-raw-recordings state rather than ready, and discovered_count == store_count + failure_count + pending_count holds in each new case.

Written by the indexing model from the issue text.

Description

data-quality zarr

Problem. When every attempted recording fails, the run writes only the callback and exits 1 (scripts/zarr/generate_zarr.py, the branch that handles attempted recordings with no converted entries and nothing to remove). No index.json is published. The API then reports the dataset as failed with its failure count, but no public reason exists. This affects the 18 no-index datasets in the gate, for example on002181 (failed, 226 failures) and nm000177 (failed, 360).

A separate path publishes a zero-store index. A run that discovers zero raw recordings publishes an index with zero stores and status ready, which is what 10 gate datasets show (converted 2026-09-06 to 09-08). Code review found no check on that path that compares the discovered set with prior stores before the --clean removal step, so a zero-discovery run could remove every prior store. This needs a reproduction in the phase's first test before it is treated as a deletion bug.

Expected. A run that attempted recordings publishes index.json with discovered_count, failure_count and failures[] populated, and the callback status is failed. A zero-discovery run publishes a typed no-raw-recordings state, never ready. A run that would remove every prior store refuses unless it is explicitly acknowledged.

Acceptance.

  • A total-failure run writes index.json with failures[] populated; the gate still treats store_count 0 as not served.
  • A zero-discovery run over a dataset with prior stores removes nothing and does not publish ready (fixture tree test).
  • A zero-discovery run with no prior stores publishes the typed state.
  • The invariant discovered_count == store_count + failure_count + pending_count holds for every new case.

Related: nemar-cli #1100 (closed diagnosis of this class), #1483.

Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
2h 52m
Merged PRs (30d)
215

Getting set up

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 nemarOrg/nemar-cli

All issues in nemarOrg/nemar-cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.