Sequential contract cancellations fail with Invalid Transaction (1010) until daemon restart #132
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_compute#132
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When cancelling several VM contracts in a row through compute.delete_vm, the first cancellation succeeds and the next ones fail with "contract cancellation failed ... RPC error: User error: Invalid Transaction (1010)". Restarting my_compute_zos_server resyncs the on-chain nonce, after which the next single cancellation succeeds, but the one after it fails again. In practice cleanup becomes one delete per restart.
It looks like the daemon does not advance its cached account nonce after a successful cancelContract, so the following transaction reuses a stale nonce. The error already hints at a recovery path (my_compute_zos_server --cancel-contracts vm net). A proper fix would refresh or increment the nonce from chain after each on-chain write so a batch of cancellations can proceed without a restart between each.
Seen on QAnet (twin 703) while decommissioning several demo testers. The forward provision path and single deletes work fine; only back-to-back cancellations hit this.
Confirming this from live onboarding on QAnet (twin 703). When a tester provisioning attempt fails partway, the tester's gateway name stays registered on chain, and because cancelling several contracts in a row hits the Invalid Transaction (1010) nonce issue described here, the cleanup does not keep up and orphaned name contracts accumulate. The next attempt to provision that same tester then fails with the name already registered on chain but no local record, so onboarding is blocked until the orphan is cancelled by hand. We just saw this end to end for one tester: cancelling the single leftover name contract let the next provisioning proceed. So this nonce bug is the root cause of the onboarding orphan pileup, not only a cleanup annoyance. Refreshing the account nonce from chain after each on chain cancel, so a batch can proceed without a restart between each, would let teardown and re provisioning run cleanly.