信頼性の高い Slack アプリを構築する

Slack アプリの構築は楽しいです。しかし、あなたのアプリは信頼できます?
自分でアプリを構築しているときに、人気のオープンソース Slack アプリに共通する 2 つの問題に気付きました。

1. 多くのアプリはイベントを同期的に処理するため、タイムアウトが発生する可能性があります。 Slack は 3 秒以内の応答を期待しますが、アプリが AI/RAG パイプラインをトリガーする場合、AI モデルが応答を生成するのに時間がかかることがあります (たとえば、新しい o1 モデルは「考える」のに最大 10 秒かかることがあります)。 Slack のベスト プラクティスでは、イベントをキューに入れて非同期に処理することを推奨しています。

2. 多くのアプリは重複したイベントを処理しません。アプリが応答しない場合、Slack はイベントを 3 回再試行します。適切に処理しないと、再試行によってアプリからの応答が重複したり、一貫性がなくなったりする可能性があります。これはユーザー エクスペリエンスの低下につながります。

オープンソースの軽量で耐久性のある実行ライブラリである DBOS Python を使用してこれらを解決する方法を次に示します。私は既製の AI/RAG ベースの Slack アプリ デモ (LlamaIndex の llamabot) から開始し、関数を軽く変更し、注釈を付けて、受信メッセージごとに DBOS ワークフローを開始できるようにしました。

メッセージディスパッチコードはシンプルです:

@slackapp.message()
def handle_message(request: BoltRequest) -> None:
    DBOS.logger.info(f"Received message: {request.body}")
    event_id = request.body["event_id"]
    # Use the unique event_id as an idempotency key to guarantee each message is processed exactly-once
    with SetWorkflowID(event_id):
        # Start the event processing workflow in the background then respond to Slack.
        # We can't wait for the workflow to finish because Slack expects the
        # endpoint to reply within 3 seconds.
        DBOS.start_workflow(message_workflow, request.body["event"])

1. ワークフローはバックグラウンドで開始され、アプリが Slack に迅速に応答できるようになります。 DBOS ワークフローは、開始されると常に完了するまで実行されます (非同期で実行される場合でも)。したがって、メッセージは常に確実に処理されます。

2. メッセージのイベント ID をワークフローの冪等キーとして使用するため、DBOS はそれを使用して各メッセージが 1 回だけ処理されるようにします。

私が構築した AI を活用した Slack アプリの詳細については、この GitHub リポジトリで見つけることができます: https://github.com/dbos-inc/dbos-demo-apps/tree/main/python/llamabot

README には、このアプリを Slack ワークスペースで直接使用する方法に関する詳細な手順が含まれています。

あなたは通常、信頼性の高いアプリケーションをどのように構築していますか?このアプリについて何かフィードバックはありますか?ぜひ教えてください！

以上が信頼性の高い Slack アプリを構築するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。