chore: added retry functionality for failing govt props

[benjamin852]

why?

current bug exists when making a govt. prop. If you wait for ~10> seconds on the submit prompt then it fails with an err due to a closed socket

• ...
• Task: ?

how?

added a simple retry functionality for when this error occurs.

• ...

testing

ran govt prop and waited for it to fail. confirmed tx still fails as it was before in the logs of the retry but now with the retry it successfully submits prop on second attempt.

• ...

Greptile Summary

Updated On: 2025-09-16 15:46:16 UTC

This PR introduces retry functionality to handle transient network failures when submitting government proposals in the CosmWasm deployment system. The change addresses a specific bug where waiting more than ~10 seconds on the submit prompt causes RPC socket closure, leading to proposal submission failures.

The implementation adds a new signAndBroadcastWithRetry function that wraps the existing client.signAndBroadcast call with intelligent retry logic. The function specifically targets transient network errors (socket closure and fetch failures) and implements exponential backoff with a maximum of 3 attempts. The retry mechanism is conservative - it only retries on known recoverable errors while preserving the original behavior for all other error types.

This change integrates seamlessly with the existing government proposal submission workflow. The submitProposal function in cosmwasm/utils.js now uses the retry wrapper instead of directly calling the client method, providing automatic recovery from common timeout scenarios without requiring users to restart the entire proposal process.

Changed Files

Filename	Score	Overview
cosmwasm/utils.js	4/5	Added retry functionality with exponential backoff for transient socket/fetch errors in government proposal submissions

Confidence score: 4/5

• This PR is safe to merge with minimal risk as it only adds retry logic for specific transient network errors
• Score reflects well-implemented error handling that preserves existing behavior while adding resilience to known failure scenarios
• The implementation is conservative and targets only specific error patterns, reducing the risk of masking legitimate failures

Sequence Diagram

sequenceDiagram
    participant User
    participant SubmitProposal as "submit-proposal.js"
    participant Utils as "utils.js"
    participant Client as "Blockchain Client"
    participant Network as "Blockchain Network"

    User->>SubmitProposal: "Execute proposal submission"
    SubmitProposal->>Utils: "submitProposal(client, wallet, config, options, content)"
    Utils->>Utils: "encodeSubmitProposal(content, config, options, account.address)"
    Utils->>Utils: "calculateFee(gasLimit, GasPrice)"
    
    loop Retry attempts (max 3)
        Utils->>Client: "signAndBroadcast(signerAddress, msgs, fee, memo)"
        Client->>Network: "Submit transaction"
        
        alt Transaction succeeds
            Network-->>Client: "Transaction response with events"
            Client-->>Utils: "Return transaction result"
        else Socket error or transient failure
            Network-->>Client: "UND_ERR_SOCKET or fetch failed error"
            Client-->>Utils: "Throw error"
            Utils->>Utils: "Log error and check if transient"
            Utils->>Utils: "Wait with exponential backoff"
            Note over Utils: "Retry with increased delay"
        end
    end
    
    alt All retries successful
        Utils->>Utils: "Extract proposal_id from events"
        Utils-->>SubmitProposal: "Return proposal ID"
        SubmitProposal-->>User: "Proposal submitted successfully"
    else All retries failed
        Utils-->>SubmitProposal: "Throw final error"
        SubmitProposal-->>User: "Proposal submission failed"
    end

Loading

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}