Failures are logged and swallowed, and the entry point has no error handler

What is wrong

Two failure paths catch, log and continue, so a run can partially fail and still exit 0. Separately, the entry point has no handler, so an error that does propagate reaches the user as a raw Node stack trace rather than a message.

Where it was observed

Catch-and-continue:

src/prettier.ts:99-101 — wrapDescription catches, calls log.error, continues. The description is then empty for that input.
src/save.ts:22-24 — catches, calls log.error, continues.

No top-level handler — src/index.ts is 16 lines and ends with a bare top-level await:

export async function generateReadme(): Promise<void> {
  const log = new LogTask('Generate Documentation');
  const inputs = new Inputs();
  const generator = new ReadmeGenerator(inputs, log);
  await generator.generate();
  return save(inputs, log);
}

await generateReadme();

Evidence

The second half is observable. Running the built binary in a directory where repository detection fails produces:

file:///…/dist/bin/index.js:42734
	throw new Error("No owner or repo found");
	      ^

Error: No owner or repo found
    at repositoryFinder (…)
    at loadDefaultConfig (…)
    at new Inputs (…)

Node.js v22.22.2

A user gets an internal stack trace with bundled line numbers.

Impact

Two distinct problems. A partially failed run — a description that failed to format, or a .ghadocs.json that failed to save — exits 0, so a CI pipeline gated on exit code treats it as success and the user has to read the log to notice. And a genuine failure is presented as a crash rather than as an error the user can act on, which is the same surface as #642.

fix: fail generation on formatting and requested save errors (#654) (#…

fix: add CLI-only generation error boundary (#654) (#725)

chore(release): 2.0.5 [skip ci]

Reconciled against merged main 3f03f0d after #732–#735 landed. All three original requirements are satisfied:

Description-formatting failure is rethrown before appending content. The rejection propagates through usage preparation, section resolution and generation to the entry boundary, preventing README persistence on that failure.
Requested .ghadocs.json persistence is awaited and retains the original rejecting error through save() and the returned promise in generateReadme(). The regression checks exact error identity; removing the production rethrow makes it fail.
The built CLI awaits dynamic import inside its error boundary, prints the error message and sets exit status 1. Both the npm binary and GitHub Action select this entry. Fresh native subprocess tests verify exact stderr/status on startup and SVG-write failures; the public ESM library preserves rejection for its caller.

An independent requirement-by-requirement source check confirmed completion. The merged unit-test jobs have passed tests, coverage, checks, builds and docs; release processing is separate and still running at this update. A configuration-save failure may occur after README generation, as before; this issue requires propagation and failing exit status, not rollback.

Closing this issue as completed. The broader #670 inventory and #631 version-resolution complexity remain separate.

Navigation Menu

Repository navigation

Failures are logged and swallowed, and the entry point has no error handler #654

What is wrong

Where it was observed

Evidence

Impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Failures are logged and swallowed, and the entry point has no error handler #654

Description

What is wrong

Where it was observed

Evidence

Impact

Activity

Jamie-BitFlight commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions