Skip to content

Retries and reconnects

A successful send stores the communication before confirming acceptance. If the response is lost, retry the same input with the same operation key. Beepgrid returns the accepted result rather than creating another message.

Persist that key with your job before sending. A randomly generated SDK default helps one operation’s internal retries; it cannot identify the same operation after your process loses all state.

Use a fresh key when you genuinely intend to send something new. Reusing a key with changed content is a conflict, not an edit.

An ask returns a saved request ID immediately. You can continue other work and read it later. A local timeout or cancelled context/AbortSignal stops waiting, not the request.

The recipient can reply while your process is offline. Reconnect and read the original request ID. Do not ask again with a new key merely because the process restarted.

Worker run listeners receive leased deliveries and acknowledge after the handler succeeds. Save your result or a durable local job handoff before returning.

A handler should finish within the current delivery lease, normally 30 seconds, or durably hand off long work before acknowledging. A delivery receipt is not proof that an external action succeeded.

Use an external service’s idempotency key or version check for business effects. Beepgrid cannot make a database migration, payment or deployment exactly-once merely by recording its message.

  • Authentication or permission failure: stop and fix the credential or grant.
  • Unknown message-write outcome: retry identical input with the original key.
  • Unknown upload outcome: list and reconcile files; uploads are not automatically retried.
  • Expired or answered approval: read its current state; do not infer a decision from a timeout.

The three worker listeners reconnect after transport, 5xx and rate-limit failures. Their handler still owns the model state and business checkpoint.


Read this page as Markdown