Skip to content

v0.5.92

Choose a tag to compare

@Oscorped Oscorped released this 06 Nov 00:28
Immutable release. Only release title and notes can be modified.
  • Direct transfers: when pay transfer approve stops at the foreground approval (it timed out, was refused or was interrupted), the error now carries next_actions instead of none, the first being apn operation resume --operation <id> --rpc-url <url> with the RPC of the approve call. Approval and signing are one native call, so the operation had already moved to started and reserved its amount in the usage ledger before the prompt, and the reservation stays held until resume. Native records a no-private-entry proof when the approval ends before the wallet is opened; the next actions are added only when that proof is present, and the resume then ends the operation as failed_before_effect, releases the reservation and asks for a new prepare. A failure after the wallet was opened, or one without that proof, keeps its own error and next actions as before. QA hit the empty next_actions after APN_APPROVAL_TIMEOUT.
  • Local gasless: when operation resume --observation-rpc-env cannot finish its observation through the named RPC, the output now says why in observation_rpc_diagnostic: the RPC origin, cause (http_<status>, APN's transport reason such as transport_request_deadline, or the error code) and rpc_error_code, the numeric code of the last JSON-RPC error. It is shown with that call only and never stored; the endpoint's error message is not included. Before, every HTTP refusal, transport failure and exhausted request budget looked the same: gasless_observation_rpc_unavailable (or gasless_receipt_unresolved for other statuses) with empty error.details. QA hit this on Optimism with an endpoint that answered the same reads when they were sent directly.
  • Stargate token: when the RPC stops answering (a non-200 status, a rate limit, a transport failure) while stargate token execute or observe observes a sent approval or bridge transaction, the error now adds sent_effect, sent_transaction_hash and operation_phase, and its next action says that rerunning the same command observes that transaction and never sends it again (after an approval, execute then continues with the bridge after its usual checks). A protocol or state refusal keeps its own error and advice. Before, an RPC refusal after the approval was sent read "Stargate native runtime unavailable: rpc_status" with the generic advice to correct the RPC setting. A non-200 Stargate RPC answer now names its status in httpStatus, and a 429 is APN_RPC_RATE_LIMITED instead of APN_RPC_CONFIG. QA saw the old text after an approval on Optimism; the rerun continued without a resend, as it does now.