DevRev Workflows の HTTP アクションでレスポンスサイズ上限 (200KB) にぶつかった話

はじめに

DevRev の Workflows は、GUI 上でトリガーやアクションを組み合わせてノーコードで自動化フローを構築できる機能です。今回、Ticket のステージ変更をトリガーにして外部 Web ページのコンテンツを取得するワークフローを構築しようとしたところ、HTTP アクション (Make HTTP requests) のレスポンスサイズ上限に引っかかりました。

この記事では、遭遇したエラーの内容と試した 3 つの回避策、そこから得られた知見を共有します。

DevRev とは

DevRev とは、カスタマーサポートや開発チーム向けのエンタープライズ AI プラットフォームです。Ticket 管理やナレッジベースなどの機能に加え、Workflows や Snap-in による自動化の仕組みを備えています。

対象読者

• DevRev の Workflows 機能を使って自動化を検討している方
• DevRev で外部 API 連携を含むワークフローを構築したい方
• Workflows と Snap-in の使い分けを知りたい方

参考

• DevRev Workflow Engine
• DevRev Action Library
• DevRev Snap-in 開発ガイド

実現したかったこと

構築したかったワークフローは次のような流れです。

Ticket の Description に DevelopersIO の記事 URL を記載しておき、ステージを Resolved にすると自動的にその記事の内容を DevRev の Article として取り込むというものです。

Workflows でトリガーとコード実行を設定する

まず、Workflows で Ticket のステージ変更を検知するトリガーを設定します。Settings > Workflows から新規ワークフローを作成し、以下のように設定します。

• トリガー: Ticket Updated
• Fields to watch: Stage
• フィルター: Ticket Updated / Output > Stage > Stage > Id が Resolved と等しい

次に、Execute Code アクションで Description から URL を抽出します。Execute Code は Python スクリプトを実行できるアクションです。

def run(inputs):
    import re
    description = inputs.get("description", "")
    match = re.search(r'https?://[^\s<>"{}|\\^`\[\]]+', description)
    return {"url": match.group(0) if match else ""}

Input Values として Ticket の Description を description という名前で渡し、Output Schema に url を定義します。

なお、Execute Code には注意すべき仕様があります。Output Schema を明示的に定義しなければ、return で値を返していても後続ステップの変数セレクターに表示されません。Output Schema の名前と return の辞書キーが一致している必要があります。

前段で Output を明示的に宣言することで Insert variable の選択肢に出現する

HTTP アクションで 200KB の壁にぶつかる

URL が抽出できたので、次は HTTP アクションでその URL にアクセスし、HTML を取得します。設定は単純で、URL に前ステップの出力変数を、Method に GET を指定するだけです。

ここで以下のエラーが発生しました。

Operation execution failed: Response body is too large.
Actual size: 209770 bytes. Allowed size: 204800 bytes.

HTTP アクションにはレスポンスボディのサイズ上限があり、204,800 bytes を超えるレスポンスは受け付けられません。DevelopersIO の記事ページは約 210KB あり、わずかに上限を超えていました。この上限は設定画面から変更できません。

3 つの回避策を試した結果

回避策 1: Accept / Accept-Encoding ヘッダーの変更

HTTP リクエストのヘッダーに Accept: text/html と Accept-Encoding: identity を追加し、サーバーからの応答を制御しようとしました。

結果は変わりませんでした。今回の対象 URL では、ヘッダーを変更しても HTTP アクションが扱うレスポンスボディサイズは 200KB 以下にならず、制限を回避できませんでした。

回避策 2: Range ヘッダーによる部分取得

HTTP の Range ヘッダーを使って、レスポンスの先頭部分だけを取得する方法を試しました。Range: bytes=0-199000 を指定し、先頭 195KB のみを要求します。<title> や <article> タグは HTML の前半に含まれるため、これで十分なはずです。

しかし、今回の対象 URL では同じエラーが発生しました。少なくともこのケースでは、Range ヘッダーを指定しても HTTP アクション上では 200KB 超のレスポンスとして扱われたため、安定した回避策にはなりませんでした。対象サーバーが Range リクエストを無視して全文を返した可能性もあり、原因の特定には至っていません。

回避策 3: Execute Code 内で HTTP リクエストを実行する

HTTP アクションを使わず、Execute Code 内で Python の urllib.request を使って直接 HTTP リクエストを送る方法を試しました。コード内であればレスポンスサイズの制限を受けないはずです。

def run(inputs):
    import urllib.request
    url = inputs.get("url", "")
    req = urllib.request.Request(url, headers={"User-Agent": "DevRev-Workflow/1.0"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        html = resp.read().decode("utf-8", errors="replace")
    # ... HTML パース処理 ...

結果は、HTTP リクエストが失敗しました。少なくとも今回検証した環境では、Execute Code から外部 HTTP リクエストを実行できませんでした。デバッグ用の出力を確認したところ、URL は正しく受け取れているものの、HTTP 通信自体ができていませんでした。

判明した Workflows の制約

今回の検証で判明した Workflows の制約をまとめます。

どのような場合に Workflows を使うべきか

Workflows は DevRev 内部のオブジェクト操作に適しています。たとえば、Ticket のステージ変更をトリガーにしてコメントを追加する、別の Ticket を作成するといった処理には問題なく使えます。

一方、外部 URL のコンテンツ取得のように 200KB を超える可能性のある外部連携が必要な場合は、Snap-in (TypeScript による関数実装) を検討すべきです。Snap-in であれば、HTTP アクションではなく TypeScript の function として外部 HTTP リクエストを実装できます。

今回のケースでは最終的に Snap-in で同等のワークフローを構築しました。取得した HTML を必要な title と body に加工してから DevRev に登録することで、HTTP アクションの 200KB 制限を回避した形です。

おわりに

DevRev の Workflows は GUI で手軽にフローを組める反面、外部連携には制約があります。特に HTTP アクションの 200KB 制限は、実際に試さないとわからないものでした。これから DevRev で外部連携を含む自動化を検討する方の参考になれば幸いです。