AntFleet's two-model review found a recoverability issue in the CLI's post-transaction confirmation path.
Summary
compute top-up and client review both broadcast an on-chain transaction first, then call a backend confirmation endpoint with the resulting transaction hash. If that backend confirmation call fails, the outer catch path reports only the backend error and the user loses the transaction hash needed to reconcile the already-broadcast transaction.
Evidence
src/commands/compute.ts, top-up action: broadcasts the top-up transaction, then calls agentApi.computeTopUpsrc/commands/client.ts, review action: broadcasts the feedback transaction, then calls agentApi.confirmJobFeedback
Impact
A user can successfully pay or submit feedback on-chain, then hit a network/server/auth-refresh failure during backend confirmation. In that case the CLI reports the backend failure but does not include the transaction hash in JSON or human-readable output. The operation becomes difficult to reconcile manually even though funds or feedback have already moved on-chain.
Suggested fix
Once a transaction has been broadcast, always surface the transaction hash even if the subsequent backend confirmation fails. A minimal fix would wrap just the backend confirmation call in its own try/catch and emit a structured error containing:
txnHash- action name, e.g.
compute top-up or client review
- backend error message
- short manual reconciliation guidance
Persisting unconfirmed actions locally for retry would also be useful, but the critical fix is making the transaction hash visible.
Suggested regression test
Mock transaction broadcast to return a known hash, then mock the backend confirmation method to reject. Assert both JSON and human output include the transaction hash so the user can recover.
AntFleet's two-model review found a recoverability issue in the CLI's post-transaction confirmation path.
Summary
compute top-upandclient reviewboth broadcast an on-chain transaction first, then call a backend confirmation endpoint with the resulting transaction hash. If that backend confirmation call fails, the outer catch path reports only the backend error and the user loses the transaction hash needed to reconcile the already-broadcast transaction.Evidence
src/commands/compute.ts, top-up action: broadcasts the top-up transaction, then callsagentApi.computeTopUpsrc/commands/client.ts, review action: broadcasts the feedback transaction, then callsagentApi.confirmJobFeedbackImpact
A user can successfully pay or submit feedback on-chain, then hit a network/server/auth-refresh failure during backend confirmation. In that case the CLI reports the backend failure but does not include the transaction hash in JSON or human-readable output. The operation becomes difficult to reconcile manually even though funds or feedback have already moved on-chain.
Suggested fix
Once a transaction has been broadcast, always surface the transaction hash even if the subsequent backend confirmation fails. A minimal fix would wrap just the backend confirmation call in its own try/catch and emit a structured error containing:
txnHashcompute top-uporclient reviewPersisting unconfirmed actions locally for retry would also be useful, but the critical fix is making the transaction hash visible.
Suggested regression test
Mock transaction broadcast to return a known hash, then mock the backend confirmation method to reject. Assert both JSON and human output include the transaction hash so the user can recover.