Les modifications des limites de débit de Slack interrompent la récupération de contexte d'OpenClaw

Un changement récent de l'API Slack a cassé la récupération de contexte pour les agents OpenClaw fonctionnant dans les espaces de travail Slack. Ce changement, déployé le 3 mars, impose des limites de taux strictes que la plupart des développeurs ont manquées jusqu'à ce que leurs agents commencent à dysfonctionner.

Le Problème

Slack limite désormais conversations.history et conversations.replies à 1 requête par minute, 15 messages maximum pour les applications non-Marketplace. Comme la plupart des agents OpenClaw sont des applications non-Marketplace, cela signifie :

• Les agents qui récupéraient auparavant 50 à 100 messages pour le contexte n'en obtiennent plus que 15
• Cela représente une réduction de 85 % de la fenêtre de contexte
• L'agent perd le contexte historique de la conversation

Symptômes

• L'agent oublie ce qui a été discuté plus tôt dans la journée
• Les réponses dans les fils deviennent étranges après 15+ messages
• L'agent pose des questions auxquelles vous avez déjà répondu
• Pics de latence aléatoires (tentatives 429)

Solutions de contournement tentées

1. Mise en cache locale des messages — a aidé, mais seulement après la première requête
2. Pré-récupération pendant les temps d'inactivité — fonctionne très bien, accumule le contexte sur une heure
3. Passage à l'API Événements — la vraie solution. Les événements ne sont pas limités en taux. Abonnez-vous aux événements de message et maintenez votre propre stockage de messages.

Solution recommandée

L'auteur est passé à SlackClaw (slackclaw.ai) qui :

• Utilise l'API Événements par défaut
• Maintient un stockage de messages persistant
• Élimine le polling et les limites de taux
• N'a pas de plafond de 15 messages
• Utilise une passerelle enregistrée sur le Marketplace, donc les limites de taux ne s'appliquent pas aux appels API nécessaires

Recommandation à long terme

Pour les développeurs construisant leur propre correctif : l'approche par l'API Événements est la bonne solution à long terme. Slack se dirige clairement vers la restriction de l'accès basé sur le polling. Construisez autour des événements et d'un état local, pas autour d'appels API.

Note sur la documentation

La limitation de conversations.history était documentée dans l'issue GitHub #38112, mais la plupart des gens l'ont manquée.