配置不会自动同步

任务永远pending

用户完成支付。积分从账户扣除。视频生成任务提交成功。

然后就没有然后了。

任务状态显示pending。五分钟后还是pending。一小时后依然pending。没有错误消息，没有失败通知，只是永远等待。

这不是偶发问题。所有AI生成任务都卡住了。图片、视频、文本——全部pending。

代码最近没有修改。队列配置检查过，正确。数据库连接正常。API密钥有效。

问题在哪里？

诊断的路径

从日志开始。api-gateway的日志显示任务成功提交到队列。数据库记录显示任务状态为pending，积分已扣除。

队列呢？检查Cloudflare Queue，消息堆积了几百条。这说明队列在接收消息，但没有被消费。

ai-processor worker呢？查看日志——没有任何输出。不是错误日志没有，是完全没有日志。

这是第一个线索。worker部署了，但像不存在一样。

检查worker配置：

wrangler secret list --name ai-processor

输出：

[]

空的。零个secrets。

对比其他workers：

• processor: 11个secrets ✅
• api-gateway: 28个secrets ✅
• ai-processor: 0个secrets ❌

找到了。ai-processor无法启动，因为它缺少所有必需的环境变量。没有数据库URL，没有API密钥，没有认证凭据。代码试图初始化连接，失败，然后静默退出。

没有错误日志，因为logger都没法初始化。

配置的独立性

为什么会缺少配置？

因为一个假设：新创建的worker会继承其他worker的配置。

这个假设看起来合理。processor和ai-processor都需要连接同一个数据库，调用同一组API。配置应该是共享的，对吧？

不对。Cloudflare Workers的架构中，每个worker有完全独立的环境。Secrets不共享，不继承，不自动同步。

当你创建ai-processor.toml，配置队列绑定，部署代码时，你只是定义了代码的运行结构。但运行时需要的环境变量——那些通过wrangler secret put设置的值——完全独立。

processor有配置，不代表ai-processor有配置。即使它们在同一个项目，同一个代码库，同一个逻辑系统里。

这种独立性是设计特性，不是bug。它让每个worker有独立的凭据，独立的权限范围。但这也意味着：配置不会自动同步。

参考 let-errors-surface 了解如何让问题暴露而非隐藏。配置缺失就是被静默掩盖的问题。参考 failure-isolation 了解如何隔离单个服务的配置问题，避免影响整个系统。

静默失败的危险

最糟糕的不是失败，而是看起来没有失败的失败。

系统各个部分都在"正常运行"：

• API接收请求 ✅
• 积分扣除成功 ✅
• 任务写入数据库 ✅
• 消息发送到队列 ✅

但实际上，整个AI生成流程完全瘫痪。用户看到的是永远pending的任务。团队看到的是堆积的队列和没有日志的worker。

这是静默失败。没有警报，没有错误日志，没有明确的信号说"这里出问题了"。系统只是停止工作，安静地，隐蔽地。

如果ai-processor启动时抛出错误："Missing SUPABASE_URL environment variable"，问题会立即暴露。但它没有。代码尝试初始化，失败，然后退出。队列消息保持unacknowledged，最终timeout并重试。整个过程无声。

用户支付了，积分扣了，但什么都没得到。这不仅是技术问题，是用户信任的问题。

验证的层次

部署不只是推送代码。部署是确保系统能够运行。

大部分时候，我们只验证前两层：

第一层：代码部署

• wrangler deploy成功
• 代码上传到Workers
• 路由配置生效

第二层：配置文件

• ai-processor.toml存在
• 队列绑定正确
• 环境变量声明

第三层：运行时配置 ← 被遗忘的层次

• Secrets实际值
• API密钥有效性
• 数据库连接凭据

第四层：功能验证

• 端到端测试
• 实际任务处理
• 监控和日志

ai-processor通过了第一层和第二层，但在第三层失败了。而第三层的失败是静默的。

如何防止

#!/bin/bash
# configure-worker-secrets.sh

WORKER_NAME=$1
REQUIRED_SECRETS=(
  "SUPABASE_URL"
  "SUPABASE_SERVICE_ROLE_KEY"
  "API_KEY"
)

echo "Checking secrets for $WORKER_NAME..."

for secret in "${REQUIRED_SECRETS[@]}"; do
  if ! wrangler secret list --name $WORKER_NAME | grep -q $secret; then
    echo "❌ Missing: $secret"
    echo "Please run: wrangler secret put $secret --name $WORKER_NAME"
  else
    echo "✅ Found: $secret"
  fi
done

# .github/workflows/deploy.yml
- name: Verify secrets
  run: |
    ./scripts/verify-worker-secrets.sh ai-processor

- name: Deploy worker
  run: wrangler deploy

- name: Smoke test
  run: ./scripts/test-worker-health.sh ai-processor

参考 query-before-assumption 了解如何用查询替代假设。这里的假设是"配置会自动存在"，查询揭示了真相："配置完全缺失"。

配置的地位

配置不是代码的附属品。它是系统运行的前提条件。

代码可以完美无缺。逻辑清晰，测试覆盖率100%，没有任何bug。但如果运行时配置缺失，代码就是一堆无法执行的文本。

这和 missing-value-cascade 的逻辑类似。一个缺失的值会导致整个调用链失效。一个缺失的配置会导致整个服务瘫痪。

配置管理常被视为"运维工作"，在开发优先级中排在后面。但它决定了系统能否真正运行。

不是"代码写完了，再配置一下"。而是"配置是交付的一部分"。

从部署到运行的鸿沟

代码部署成功，不代表系统在运行。

中间有一道鸿沟，叫配置。它是隐形的，直到系统失效。

这和 from-intent-to-architecture 讨论的"从意图到实现的鸿沟"类似。意图是"部署新服务"，实现包括代码、配置、验证的完整链路。忽略任何一环，鸿沟就存在。

这道鸿沟包括：

• 环境变量的实际值
• API密钥的有效性
• 数据库连接的权限
• 服务间的网络可达性
• 依赖服务的可用性

每一项都可能成为阻塞点。每一项都需要显式验证。

验证不是可选的附加步骤。验证是部署的一部分。

ai-processor的修复不复杂。配置missing的secrets，重新部署，测试。十分钟解决。

但发现问题用了两天。因为问题是静默的，因为假设配置会自动存在，因为验证不够全面。

最后

配置不会自动同步。每个服务有独立的运行时环境。

这不是缺陷，是架构选择。独立性带来隔离性和安全性，但也要求显式配置。一个服务的凭据泄露不会影响其他服务。代价是，你不能假设"新服务会自动获得配置"。

从代码到运行，有一道鸿沟。跨越它需要验证、检查清单、自动化。

ai-processor的修复用了十分钟，但发现问题用了两天。因为静默失败，因为假设存在，因为验证不够。

不要假设。显式验证，每一次。