Retry connected app tools without creating duplicate effects
Retain operation identity, concrete arguments and provider evidence across timeouts and durable recovery.
Record selected account, discovery version, exact approval and operation outcome without collecting OAuth secrets.
An audit should explain what the human requested, which account was chosen, which discovered tool was proposed and what the provider reported. Store those as connected references rather than an unstructured dump of the entire conversation. A tool name alone cannot establish the account or version that ran. Keep the workflow’s stated purpose and a private task identifier with the execution record. This helps a reviewer distinguish an intended action from a repeated retry or a tool selected because an external document contained misleading instructions.
Save connection_id, connection_revision, tool_slug and the concrete version returned by discovery. Retain the schema or a stable digest appropriate to your audit requirements and note when it was reviewed. Lupin checks metadata again before executing and rejects mismatched toolkit or deprecated versions. These checks make a concrete approval reproducible, but provider descriptions remain untrusted data. Record that they were consulted as capability evidence rather than treating their wording as a trusted policy source. A provider documentation update should not silently rewrite the historical explanation of an already completed action.
The approval record should identify the authenticated decision and exact proposed arguments, with sensitive content protected according to workspace policy. Account replacement or argument changes require fresh approval rather than amending the old record to look current. In the Lupin consumer agent, apparent reads are also executions requiring approval; MCP clients must record the authorization they obtain themselves. A phrase spoken during a voice call is not the authenticated pending-action grant. Preserve those distinctions so later reviewers can understand which interface established authority and whether the proposed effect matched the completed one.
Execution returns a local operation ID, successful flag, result data and provider log reference when supplied. Keep the operation key privately with its approved payload so retries can be correlated. If a timeout leaves the outcome uncertain, record uncertainty and its reconciliation history rather than replacing it with a generic failed status. A later recovered local result should point back to the original effect. Do not equate an unsuccessful provider result with proof that no partial change occurred, and do not erase a durable journal simply to make an audit dashboard appear tidy.
OAuth secrets, API keys and raw authorization URLs do not belong in audit records. Keep only the content necessary to explain the effect and apply the workspace’s retention and access rules to arguments and returned data. For a public incident report, use synthetic resource names and narrow error facts. A useful audit fixture follows one approved action through a lost response and same-key recovery, then checks that there is one effect with a complete evidence chain. Another swaps the account revision after approval and verifies that the rejected attempt remains visible without creating an external change.
A recovered action can have several local request attempts but only one provider effect. The audit should group those attempts under the original operation and show the eventual known result. Counting each retry as a separate successful action distorts both reliability and cost analysis, while erasing retries conceals the failure that recovery successfully handled.
Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.