Context
Follow-up from #141 / #142 (the unexpected_user_agent force-logout fix). Enterprise session-security anomaly detection plausibly also weighs request velocity/pattern, not just header fingerprint: a burst of API calls in a shape no human browser tab would produce (rapid-fire, evenly spaced, or unusually high-volume) is itself a signal a real user's browsing wouldn't generate.
agent-slack already has AGENT_SLACK_RATE_LIMIT_MAX_WAIT_MS (src/slack/client.ts), but that's reactive: it only kicks in after Slack responds 429 and asks us to back off. There's currently nothing that proactively paces outgoing requests before Slack complains.
Proposal
Add a lightweight, optional client-side throttle for browser-session (xoxc/xoxd) API calls specifically (standard bot-token auth via the Slack SDK's WebClient already has its own rate-limit handling and isn't the concern here):
- A minimum inter-request delay, with jitter, between successive
browserApi/browserApiMultipart calls in src/slack/client.ts.
- Configurable via an env var (e.g.
AGENT_SLACK_MIN_REQUEST_INTERVAL_MS), defaulting to something small enough not to meaningfully slow normal usage, but enough to avoid a machine-gun burst pattern during bulk operations (e.g. message list pagination, bulk search).
This is a defense-in-depth measure. We don't have confirmation that request velocity is actually part of Slack's anomaly signal (unlike the UA case, which was directly reproduced), so this should be scoped as a cheap, low-risk mitigation rather than a confirmed fix.
Context
Follow-up from #141 / #142 (the
unexpected_user_agentforce-logout fix). Enterprise session-security anomaly detection plausibly also weighs request velocity/pattern, not just header fingerprint: a burst of API calls in a shape no human browser tab would produce (rapid-fire, evenly spaced, or unusually high-volume) is itself a signal a real user's browsing wouldn't generate.agent-slackalready hasAGENT_SLACK_RATE_LIMIT_MAX_WAIT_MS(src/slack/client.ts), but that's reactive: it only kicks in after Slack responds429and asks us to back off. There's currently nothing that proactively paces outgoing requests before Slack complains.Proposal
Add a lightweight, optional client-side throttle for browser-session (xoxc/xoxd) API calls specifically (standard bot-token auth via the Slack SDK's
WebClientalready has its own rate-limit handling and isn't the concern here):browserApi/browserApiMultipartcalls insrc/slack/client.ts.AGENT_SLACK_MIN_REQUEST_INTERVAL_MS), defaulting to something small enough not to meaningfully slow normal usage, but enough to avoid a machine-gun burst pattern during bulk operations (e.g.message listpagination, bulksearch).This is a defense-in-depth measure. We don't have confirmation that request velocity is actually part of Slack's anomaly signal (unlike the UA case, which was directly reproduced), so this should be scoped as a cheap, low-risk mitigation rather than a confirmed fix.