Q: 同じフローの2つの実行が重なったときに、flow dedup がアイテムを誤って seen としてマークしてしまうのはなぜですか？

これは競合状態（race condition）が原因でした。dedup ノードが共有の `dedup: :tentative` セットに書き込んでいたため、正常に完了した実行が、まだ実行中（または失敗）の重複した実行の tentative キーをコミットしてしまう可能性があり、また確定処理が実行開始時のグラフではなく、現在保存されているフロー定義を使用していました。修正は TinyFlows v0.8.29（tinyhumansai/tinyflows#165）でリリースされ、tentative キーが実行ごとにスコープ化され（`dedup: :tentative: `）、実行の永続化されたグラフスナップショットから確定処理が行われるようになりました。OpenHuman を PR #8170 を含むビルドにアップグレードしてください（TinyFlows が v0.8.29+ に更新されます）。旧バージョンでの回避策: 共有の tentative セットは同時実行間でのみ衝突するため、同じフローの重複・並行実行は避けてください。

Question 1

なぜtask-state compactionは504 Gateway Timeout後に会話履歴をサイレントに失うのか、またそれを修正するにはどうすればよいか？

Accepted Answer

コンパクションの試行ループは markup/JSON のパース失敗しかリトライしていなかったため、マネージドゲートウェイからのリトライ可能な 504 は最初の試行でチャンクをドロップし、以前の状態を保持したまま、依然として `degraded=false` と報告していました（`chunks_skipped=2 degraded=false`）。長いスレッドでは、履歴のほとんどが決定論的レジャーとしてのみ残ることになります。修正方法: 試行ループ内でリトライ可能なトランスポートエラー（5xx/タイムアウト）をリトライし、スキップされたチャンクをすべて degraded として報告するようになった tinyagents PR #427（ベンダリングされた tinyagents 経由で main にマージ済み、回帰テスト付き）を含むビルドに更新してください。アップグレードまでの回避策: `agent/tinyagents/harness_context_ladder.rs` のマネージドルートのチャンク上限（`(window*2/5).clamp(4_000, 100_000)` の設定）を最大 100k から約 40～50k トークンに引き下げ、1回の呼び出しが約 60 秒のゲートウェイタイムアウト内に完了するようにしてください。

Question 2

OpenHumanワークフローが"Completed"と表示されているのに、出力が表示されないのはなぜですか？

Accepted Answer

根本原因（修正済み）：コードノードが存在しない `item` 変数を参照していました。ランタイムが実際に渡すのは `input` で、ペイロードは `.json` の下にあるアイテムの配列です。また、ドライランではコードノードがスタブ化されていたため、クラッシュするスクリプトが正常であると誤って報告されていました。

修正方法：
1. TinyFlows v0.8.29+ を同梱する OpenHuman ビルドに更新してください（tinyflows#166、tinyagents#503、OpenHuman #8170/#8179 で統合）。ドライランで未実行のコードノードとバインドされていない `item` の読み取りが検出されるようになり、失敗したエージェント実行では実際のエラーがログに記録されます。
2. 既存のワークフローでは、コードノードを `item` ではなく `input` を使用するように書き換えてください。例：`input[0].json` でペイロードにアクセスします。

診断方法：実行の詳細を開き、各ステップの出力を展開してください。出力が空または `null` と表示されているステップが、サイレントに失敗したステップです。最新のビルドでも問題が解決しない場合は、その実行のステップ出力を添付して新しい issue を作成してください。

Question 3

なぜ credential_scrub はツール出力内の 'accessToken: string' や 'action.payload' のような通常のソースコードをリダクトするのですか？

Accepted Answer

これは tinyinference の sanitize.rs における既知の過剰リダクションのリグレッションで（コミット a5f129d、PR #60 で導入されました）、`looks_like_secret` は裸の識別子がキーと一致した場合にのみそれを除外し、型注釈の免除は大文字で始まる型のみを対象とし（TS の `string` は対象外）、`SENSITIVE_KV_REGEX` は `action.payload` のようなドット区切りのパスを丸ごと捕捉していました。これは tinyinference PR #95 で修正されています。tinyinference の main（またはビルドに vendored された tinyinference）に更新することで、型注釈（`accessToken: string`）やドット区切りのメンバーパスはリダクトされずに通過し、実際のシークレット（例: `password=correcthorse`、実際のトークン）はリダクトされたままになります。注意: `*_KEY` の下の短い引用符付きの値は、設計上リダクトされたままです。

Question 4

バックグラウンドタスクからの承認リクエストが常にタイムアウトして拒否されるのはなぜですか？

Accepted Answer

バックグラウンドタスク（リモートチャネルトリガー、ワークフロー自動化、ゴール継続）は、インタラクティブセッションがアタッチされていない状態で承認リクエストを発生させるため、従来はそれらを判定する手段がなく、常にTTL-denyによって期限切れとなっていました。これは #6491 で修正されました。バックグラウンドタスクからパークされた承認は、`/chat` ページ上でアクション可能な承認バナーとして表示されるようになり、事後的に承認または拒否できるようになり、すべての判定は `approval_decide` を介して監査証跡に書き込まれます。これらの発生元（ExternalChannel、TrustedAutomation、`require_approval:true` が設定された Workflow）は、フェイルクローズドのセキュリティ姿勢として、自動許可するのではなく意図的にパークすることに注意してください。これは意図された動作です。既知の制限：アプリが閉じている間に発生したパークは、600秒のTTLが期限切れになった後も拒否されます。保留中の承認を取りこぼさないようアプリを開いたままにし、TTL-denyされたリクエストの監査レコードについては `pending_approvals` テーブルを確認してください。

Question 5

同じフローの2つの実行が重なったときに、flow dedup がアイテムを誤って seen としてマークしてしまうのはなぜですか？

Accepted Answer

これは競合状態（race condition）が原因でした。dedup ノードが共有の `dedup::tentative` セットに書き込んでいたため、正常に完了した実行が、まだ実行中（または失敗）の重複した実行の tentative キーをコミットしてしまう可能性があり、また確定処理が実行開始時のグラフではなく、現在保存されているフロー定義を使用していました。修正は TinyFlows v0.8.29（tinyhumansai/tinyflows#165）でリリースされ、tentative キーが実行ごとにスコープ化され（`dedup::tentative:`）、実行の永続化されたグラフスナップショットから確定処理が行われるようになりました。OpenHuman を PR #8170 を含むビルドにアップグレードしてください（TinyFlows が v0.8.29+ に更新されます）。旧バージョンでの回避策: 共有の tentative セットは同時実行間でのみ衝突するため、同じフローの重複・並行実行は避けてください。

OpenHuman

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト