Skip to content

fix(cli): exit non-zero when miner post / miner check report success: false#843

Open
ebios-star wants to merge 1 commit intoentrius:testfrom
ebios-star:fix/miner-cli-exit-codes-on-zero-success
Open

fix(cli): exit non-zero when miner post / miner check report success: false#843
ebios-star wants to merge 1 commit intoentrius:testfrom
ebios-star:fix/miner-cli-exit-codes-on-zero-success

Conversation

@ebios-star
Copy link
Copy Markdown
Contributor

Summary

`gitt miner post` and `gitt miner check` already encode their logical outcome in the JSON `success` field (`accepted_count > 0` / `valid_count > 0`), but the process exit code stayed `0` even when every validator rejected the broadcast or no validator had a valid stored PAT. Shell pipelines and CI steps that ran `gitt miner post && next-step` or used the exit code as a health-check signal silently treated total failure as success.

After this change both commands `sys.exit(1)` when their respective count is zero — matching the JSON `success` field and the family already fixed for `gitt admin` / `gitt vote` / `gitt harvest` in #707 and `gitt issues list --id` / miner-check JSON aggregate counts in #724.

The fix is minimal: 6 lines in post.py and 6 lines in check.py, each guarded so the success exit code stays `0`.

Related Issues

Closes #841 (`gitt miner post`)
Closes #842 (`gitt miner check`)

Type of Change

  • Bug fix
  • New feature
  • Refactor
  • Documentation
  • Other

Testing

  • New `TestMinerPostExitCodeOnZeroAccepted` — 2 cases (zero-accepted exits 1, at-least-one-accepted exits 0).
  • New `TestMinerCheckExitCodeOnZeroValid` — 2 cases (zero-valid exits 1, at-least-one-valid exits 0).
  • The harmless "coroutine never awaited" RuntimeWarning that fires because we patch `asyncio.run` is filtered at class scope.
  • `uv run --extra dev pytest tests/` — 647 tests pass (643 baseline + 4 new).

Checklist

  • Code follows project style guidelines
  • Self-review completed
  • Changes are documented (if applicable)

… false

`gitt miner post` and `gitt miner check` already encode their logical
outcome in the JSON `success` field (`accepted_count > 0` / `valid_count > 0`),
but the process exit code stayed 0 even when every validator rejected the
broadcast or no validator had a valid stored PAT. Shell pipelines and CI
steps that ran `gitt miner post && next-step` or used the exit code as a
health-check signal silently treated total failure as success.

After this change both commands sys.exit(1) when their respective count
is zero, matching the JSON `success` field and the family already fixed
for `gitt admin`/`gitt vote`/`gitt harvest` in entrius#707 and `gitt issues
list --id` / miner-check JSON aggregate counts in entrius#724.

Add four regression tests under TestMinerPostExitCodeOnZeroAccepted and
TestMinerCheckExitCodeOnZeroValid (zero-success exits 1, non-zero
success exits 0). The harmless "coroutine never awaited" RuntimeWarning
that fires because we patch asyncio.run is filtered at class scope.

Closes entrius#841
Closes entrius#842
@xiao-xiao-mao xiao-xiao-mao Bot added the bug Something isn't working label Apr 28, 2026
@ebios-star
Copy link
Copy Markdown
Contributor Author

@anderdc @LandynDev — friendly ping for review when you have a moment.

Closes #841 and #842. gitt miner post and gitt miner check already declared success: false in their JSON output when no validator accepted / had a valid PAT, but the process exit code stayed 0 — so any shell pipeline using miner post && next-step or miner check as a health-check signal silently treated total failure as success.

Same family as #707 (your merged gitt admin/vote/harvest exit-code fix) and #724 (which fixed the JSON aggregate counts on miner check but left the exit-code half open). 6 lines per command + 4 new regression tests across two test classes.

Happy to rebase if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] gitt miner check exits 0 even when no validators have a valid PAT stored [Bug] gitt miner post exits 0 even when all validators reject the PAT

1 participant