Files
Arcrun/registry/examples/parallel-fanout/workflow.yaml
T
Leo e8bd518efa D36 第0步:範例 workflow 金鑰統一走 credential(止血——範例是用戶照抄的樣板)
改前四種寫法並存、沒一個是 credential,而執行端只認 {{credential.X}}
(graph-executor.ts:247→resolveCredentialRefs)⇒ 用戶照抄必踩坑:
  {{api_key}} 13/{{gitea_token}} 2/{{secret.GITHUB_BOT_TOKEN}} 2/{{kbdb_api_key}} 1

改後(19 處統一):
  {{credential.arcrun_namespace}} 15/{{credential.gitea_token}} 2/{{credential.github_bot_token}} 2

⚠️ 中途修正一次錯誤命名:我先改成 kbdb_partner_key(照零件契約舊敘述 ak_xxx),
leo 當場指正「現在沒有 partner key,改用 namespace,沒有發 API key 的機制」——
實際機制確為 X-Arcrun-API-Key: <namespace>(實例上活的 workflow 為證)。

不動:{{secret.LEO_TELEGRAM_CHAT_ID}} 3 處——chat_id 是聊天室 ID 不是金鑰,
無腦套規則會引進「找不到 credential」的錯誤。

驗:違規寫法歸零/12 個範例 YAML 全可解析。
殘:kbdb_upsert_block 契約仍寫『KBDB partner key(ak_xxx)』=假資訊源(我就是被它騙的),
修它被 component-guard 擋(正確),需 leo 跑 scripts/component-arm.sh。
2026-07-29 19:33:46 +08:00

36 lines
1.2 KiB
YAML

name: parallel_fanout
description: 一份輸入分發多個子 workflow 並行處理(trigger_workflow 模式)
flow:
- "input >> ON_SUCCESS >> dispatch_to_summary"
- "input >> ON_SUCCESS >> dispatch_to_translate"
- "input >> ON_SUCCESS >> dispatch_to_classify"
config:
# 三個並行子 workflow 觸發。各自獨立執行、互不影響、不等彼此
# cypher-executor 處理 fan-out:三條邊同源 (input) → 三個目標各自跑
dispatch_to_summary:
component: trigger_workflow
workflow_name: "llm_classify_example" # 改成你的 summary workflow
api_key: "{{credential.arcrun_namespace}}"
input:
api_key: "{{credential.arcrun_namespace}}"
text: "{{input.text}}"
dispatch_to_translate:
component: trigger_workflow
workflow_name: "your_translate_workflow"
api_key: "{{credential.arcrun_namespace}}"
input:
api_key: "{{credential.arcrun_namespace}}"
text: "{{input.text}}"
target_lang: "{{input.target_lang}}"
dispatch_to_classify:
component: trigger_workflow
workflow_name: "llm_classify_example"
api_key: "{{credential.arcrun_namespace}}"
input:
api_key: "{{credential.arcrun_namespace}}"
text: "{{input.text}}"