onboarding agent sent duplicate slack invites after api timeout

TL;DR

Your onboarding agent timed out waiting for Slack's invite API, assumed the invite failed, retried, and the user got two or three invites: the first call had actually succeeded. The fix: treat timeouts as "unknown," not "failed." Check whether the invite exists before retrying, and make the invite step idempotent so a retry is a no-op when the user is already invited.

The error

Slack API: invite call timed out after 30s
User received 3 invite emails; agent log shows 3 attempts

Steps

1. Confirm the pattern. Match the agent's retry log against the invites users received. Expected output: every duplicate invite follows a timeout, not a clean error.
2. Change timeout handling to check-then-retry. On timeout, query for the pending invite or invited user before sending another. Expected output: the check finds the first invite and the retry is skipped.
3. Make the invite step idempotent. Key the operation on the user's email so re-running it for an already-invited user does nothing. Expected output: running the step twice produces one invite.
4. Cap retries with backoff. Limit to a small number of attempts with growing delays. Expected output: the agent stops after the cap instead of looping.
5. Replay a timeout scenario in staging. Expected output: one invite per user even when the API times out.

When to use

• Users report receiving multiple Slack invites
• Duplicates always follow timeout errors in the agent log
• The agent retries API calls without checking state first

When not to use

• Invites never arrive: the call is failing for real, fix the failure
• Users get invites they should not: an authorization or targeting bug
• Slack returns a clean error like "already_invited": handle that error, not the timeout

Tool compatibility

Slack admin invite APIs and any agent framework with retry logic (LangChain, CrewAI, custom orchestrators). The check-then-retry pattern applies to any invite or provisioning API with ambiguous timeouts.

Variant phrasings

slack duplicate invites onboarding

Timeouts retried as failures; check state first.

agent retried timed out api call

Treat timeout as unknown, verify, then retry.

slack invite sent twice

Idempotent invite step fixes it.

onboarding agent duplicate actions

Every mutating step needs a pre-check.

Why it happens

A timeout tells you nothing about what happened server-side: the request may have succeeded, failed, or never arrived. Agents that map timeout to failure will retry a call that already worked, and invite APIs are happy to send another email. The deeper issue is that the agent's world model has no "unknown" state for side effects. Adding one check (does the invite already exist?) before each retry closes the hole for every API with this shape, not just Slack.

Edge cases

• The check API is also slow: cache the invite state briefly so the pre-check does not add another timeout path.
• Slack rate-limits the check calls: batch the checks or space them out.
• The user was invited, deactivated, then re-invited: the pre-check must distinguish "invited and active" from "invited then removed."
• Partial failures in bulk onboarding: track per-user state so one timeout does not restart the whole batch.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l8sK2-J4ETgtshZGPIi19Q