Retry connected app tools without creating duplicate effects

Define one logical action before sending it

A tool execution should represent a specific account, tool version and exact argument set. Generate and persist its idempotency key before submission, alongside the human approval context. A retry means asking for the outcome of that same action, not creating a similar new one. This distinction matters even for apparent reads because the underlying toolkit can have side effects or usage costs. An issue creation with a changed title or another account is a new proposal, while a lost response for the original request remains the original uncertain effect.

Keep discovery identity in the request

Lupin execution accepts the concrete version, connection_revision and arguments for a discovered tool. The route verifies account ownership, active status, toolkit membership and matching metadata before it contacts Composio. It hashes the provider account, tool, version and arguments into the durable operation identity checks. Reusing a key with different input returns an idempotency conflict rather than applying the new payload. Do not update an operation’s arguments in place to make a retry pass; create a fresh approved task only after the earlier outcome has been resolved.

Distinguish a known result from an uncertain result

When a provider outcome is durably known, Lupin can replay the saved result or finish its local projection without executing the provider tool again. A timeout or server interruption can leave the effect uncertain, so the operation and usage reservation remain recorded. The absence of a success response does not prove that no issue, message or event was created. Preserve the returned operation ID and any log reference. Do not immediately retry under a new key or let a generic network library transparently regenerate the operation identity on every request.

Reconcile before repeating the outward action

An operator can inspect the recorded provider operation and external resource evidence to determine what happened. If the action completed, recover the local result rather than issuing it again. If the state is unresolved, keep the task pending and tell the owner what is known. An unsuccessful provider tool result is also not always equivalent to no side effect; inspect the returned data before deciding whether a corrected action is needed. Restoring account authorization through reconnect is separate from deciding whether the earlier execution already changed the external application.

Test retries by counting provider requests

Use a fake Composio endpoint that records every execution. Simulate a successful provider effect followed by lost local persistence, then repeat the same approved request and key. The assertion is exactly one provider execution with eventual stable local output. Add concurrent requests, changed arguments under the same key and an unresolved timeout. Verify that the latter retains an uncertain operation rather than sending another effect. These tests exercise the actual reliability contract, while a test that merely calls the same function twice without a failure boundary can miss the duplication risk.

Distinguish correction from retry

Changing an approved issue title after a provider validation rejection is a corrected proposal, while resubmitting the identical approved title after a lost response is a retry. Keep those paths explicit in the client. The former may need fresh approval and an operation identity; the latter must preserve the existing key and resolve its recorded outcome.

Sources & verification

Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.

• Lupin connections ↗Checked 2026-11-05
• Composio execute tool API ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.