Dify 中级实验（16）：错误处理与降级——工作流如何有尊严地失败？

Dify 中级实验16错误处理与降级——工作流如何有尊严地失败Dify 实验系列 · 中级 16/20 | 实验编号DIFY-102-171. 实验目的掌握生产级 Workflow 的错误处理设计节点级异常捕获、状态码分级降级、日志与告警、超时与重试。核心观点一句话——错误不是「如果发生」而是「什么时候发生」没有错误处理的应用一个异常就能让整条链路崩溃而我们要做的是让它有尊严地失败降级优于报错报错也要留痕。2. 场景设计应用上线后常见的「想不到」外部 API 返回 500、模型超时限流、代码节点抛异常。本实验搭一个「容错架构演练」工作流用httpbin.org 可控状态码端点模拟外部 API输入input_data任意文本作为请求内容主链路HTTP 请求https://httpbin.org/status/500→ 按状态码分流500 降级 / 200 正常→ 统一日志判定 → 严重级别判断 → 告警或正常收尾重点观察同一个 HTTP 节点如何把「业务失败500」和「网络失败超时/断连」分开处理。3. 节点拓扑开始input_data ↓ 请求APIHTTPhttpbin.org/status/500超时 5s重试 2 次error_strategyfail-branch ↓ 状态码判断IF-ELSE ├── case_500status_code 500→ 降级处理Code→ 日志判定Code→ … └── case_200status_code 200→ 正常处理Code→ 日志判定Code→ … ↓ 严重级别判断IF-ELSE ├── case_critical → 告警模拟Code→ 告警说明LLM→ 结束 └── case_warning / case_info → 正常说明LLM→ 结束12 个节点、13 条边。关键设计降级路径和正常路径在「日志判定」节点汇合——无论哪条路错误都要被记录、分级、决定是否告警。4. 关键配置4.1 HTTP 节点核心type:http-requesturl:https://httpbin.org/status/500method:gettimeout:{connect:5,read:60,write:20,max_connect_timeout:300,max_read_timeout:600,max_write_timeout:600}retry_config:{max_retries:2,retry_enabled:true,retry_interval:1000}error_strategy:fail-branchauthorization:{config:null,type:no-auth}ssl_verify:true要点超时 5 秒 重试 2 次间隔 1s——瞬时抖动自动扛过去error_strategy: fail-branch让节点长出两个输出口成功口source和失败口fail——500 属于「请求成功但业务失败」走成功口再判断fail口只管网络层失败超时/断连/无响应体4.2 状态码判断IF-ELSE数字比较必须写全varType: numbernumberVarType: constant值仍是字符串字面量cases:-case_id:case_500conditions:-comparison_operator:# 数字比较用 字符串比较才用 isnumberVarType:constantvalue:500variable_selector:[http_call,status_code]varType:numberlogical_operator:and-case_id:case_200conditions:-comparison_operator:numberVarType:constantvalue:200variable_selector:[http_call,status_code]varType:numberlogical_operator:and4.3 日志判定节点Code两条路径在此汇合把错误转成可观测的结构化日志并输出告警开关boolean 展平成 stringdefmain(status_code:int,user_input:str,degrade_message:str,normal_message:str)-dict:importtimetry:codeint(status_codeor0)exceptException:code0ifcode500:severitycriticalelifcode400:severitywarningelse:severityinfomessagedegrade_messageornormal_messageorlog_idERR-{}.format(int(time.time()))return{severity:severity,log_message:message,log_id:log_id,need_alert:trueifseveritycriticalelsefalse}severity分级critical/warning/info直接驱动下游严重级别判断critical 才触发告警warning/info 只记日志正常收尾——不是所有错误都要惊动告警通道。5. 运行验证场景操作预期实测结果业务失败保持httpbin.org/status/500状态码 500 → 降级处理 → severitycritical → 告警输出500 分支触发告警模拟节点执行 ✓正常响应把 URL 改为httpbin.org/status/200状态码 200 → 正常处理 → severityinfo → 正常说明200 分支触发正常收尾 ✓超时降级改为不可达域名如httpbin.org:81网络层失败走 fail 口需在完整版中把 fail 口接降级节点见采坑点运行日志里核对HTTP 节点耗时、状态码值、log_id时间戳、最终输出内容。6. 采坑点坑现象修复httpbin.org 外网不稳定演示时偶发超时/连接失败工作流卡住或直接失败教学演示可临时改用本地 mock代码节点模拟响应生产环境把 fail 口接到降级分支fail-branch 的 fail 口没接线网络层失败超时/断连时没有出路整条链路失败完整版把fail口接「网络降级」节点记住 fail 口只管网络层4xx/5xx 状态码走成功口把 500 判断接到 fail 口500 有响应体但 fail 口不触发降级逻辑永远不执行500 走成功口 if-else 判断status_codefail 口只接超时/断连类降级数字比较漏写varType状态码判断不生效或校验报错数字条件补varType: numbernumberVarType: constant运算符用/≥/≤Unicodeneed_alert用 boolean 输出下游 IF-ELSE 判断不到类型不可见展平为 stringtrue/false采坑点来自本实验 DSL 生成与运行验证的真实记录fail-branch 双口语义、httpbin 外网依赖、数字比较格式。7. 实验文档及源码获取实验文档完整操作步骤DIFY-17错误处理与降级架构.md源码可直接导入dify102_17_容错架构演练.ymlDSL 目录dify-102/dsl/文章聚焦核心配置与采坑点实验文档还包含降级回路简化提示重试→静态回复、迭代超时控制、HTTP 超时链、熔断模式、渐进式降级L1-L4等完整设计。下一篇Dify 中级实验17调试监控与性能优化——响应慢和 Token 超支如何定位