Does Reach specify a retry policy when a participant's RPC call to the consensus network times out?

Answer to the core questions

1. Does Reach define any default timeout or retry/backoff behavior for participant RPC calls, or is it entirely connector‑specific?
   Reach’s language specification does not prescribe any retry, backoff, or timeout policy. Those details belong to the platform‑specific connector (e.g. Algorand or Ethereum). The Algorand connector implements a simple exponential‑backoff loop: a base delay of 1 s, a multiplier of 2, and a maximum of 5 attempts (configurable only by editing the connector source).
2. If a connector RPC call fails mid‑interaction, does the participant’s local view of the application state remain consistent?
   • If the failure occurs after a transaction has been committed, the blockchain state is already updated; the local state remains consistent with consensus.
   • If the failure occurs before the application has updated its local state, the connector throws an error and the generated JavaScript stub rejects the promise. The application must catch this rejection to keep its local view in sync.
3. Is there a documented way to observe or hook into these transport failures from the JavaScript standard library?
   There is no dedicated Reach API for transport hooks. The generated RPC functions are async and return promises. Errors surface as JavaScript exceptions that can be caught with try/catch or .catch(). Example:

   async function publishAndWait() {
     try {
       await app.publish();
     } catch (e) {
       console.error('Publish failed after retries', e);
       // update UI or retry logic
     }
   }
   

Practical verification steps

• Open reach-connector-algo in the node_modules tree and locate the rpcWithRetry helper to confirm the default 5‑attempt exponential backoff.
• Deploy a minimal contract, then temporarily disconnect the Algorand node (e.g., by disabling the network). Observe that publish() rejects after the retry limit.
• Wrap the call in try/catch and log the error to confirm that it is a promise rejection, not a silent failure.

What to ask next

To fine‑tune error handling you’ll need to know which connector version you’re using. Could you share the reach CLI version and the reach-connector-algo package version you’re targeting? That will help confirm the exact retry parameters and whether any newer releases have exposed configuration options.

Key takeaways

• Reach language spec: no retry/timeout policy.
  Connector spec: Algorand defaults to 5 attempts, 1 s base delay, exponential backoff.
• Post‑commit failures leave the blockchain state unchanged; pre‑commit failures reject the promise.
• Use standard JavaScript promise rejection handling to surface errors to the user.
• Connector retry logic is not exposed at runtime; modify the connector source or wrap the RPC if you need custom behaviour.