Chainlink CRE 本地环境拓扑workflow-gateway-don-grpc-source 的 gRPC 附加工作流源实战指南【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink本文档面向需要在本地搭建 Chainlink CREChainlink Runtime Environment开发环境的开发者深入剖析workflow-gateway-don-grpc-source这一单 DONsingle-don类拓扑它由 1 个bootstrap-gateway节点与 4 个workflow节点组成并通过Capabilities.WorkflowRegistry.AdditionalSources配置将工作流元数据的来源从链上注册合约扩展到本地 gRPC 服务host.docker.internal:8544。读完本文你将掌握该拓扑的配置逐项含义、gRPC 附加源的配置语法与源码级实现原理以及如何用仓库中的冒烟测试验证工作流的部署、暂停、恢复与删除全生命周期。拓扑概览一条配置、两个 DON、三类职责该拓扑的官方定义位于 core/scripts/cre/environment/docs/topologies/workflow-gateway-don-grpc-source.md其对应的真实配置文件为 core/scripts/cre/environment/configs/workflow-gateway-don-grpc-source.toml。文档元数据给出了三个关键标识Configconfigs/workflow-gateway-don-grpc-source.tomlClasssingle-donInfradocker「Class: single-don」表示这是一类「单一 DON 家族」拓扑其下所有节点共享同一个don_family本例为test-don-family。在 docs/TOPOLOGIES.md 生成的总览表中它与其他 10 个拓扑并列登记DON 数为 2。该总览文件由go run . topology generate自动生成因此如果要快速在终端查看可用拓扑官方建议执行cd core/scripts/cre/environment go run . topology list底层实现位于 core/scripts/cre/environment/environment/topology.godiscoverTopologies()会递归扫描configs/目录下所有 TOML凡同时包含blockchains、nodesets、jd、infra四个节见topologyProbe结构与isTopologyConfig()即被识别为拓扑配置随后topology generate为每个配置生成对应的 Markdown 文档并写入docs/topologies/。这也解释了为什么该拓扑文档与workflow-gateway-don.md的骨架几乎一致——差异全部体现在配置内容上。Capability Matrix能力矩阵是能力归属的真相来源文档中的能力矩阵Capability Matrix是「按 DON 放置能力」的权威依据本拓扑的完整矩阵如下Capabilitybootstrap-gatewayworkflowconsensus-localcron-localdon-time-localevm-local (1337,2337)http-action-localhttp-trigger-localvault-local解读要点全部 7 类能力共识、定时任务、DON 时间、EVM、HTTP 动作、HTTP 触发、Vault都以local模式挂载在workflowDON 上即由 DON 内节点本地运行、通过 DON 内部消息传递发现而非通过网关从远程暴露。evm能力标注为local (1337,2337)对应拓扑中两个 Anvil 链的 chain_id。bootstrap-gateway不承载任何能力其职责是提供 P2P 引导bootstrap与外部流量入口gateway。这一矩阵与 workflow-gateway-don.md无 gRPC 源的姊妹拓扑完全相同说明引入 gRPC 附加源不改变能力分布只改变工作流元数据的获取路径。能力到 DON 的映射在配置中由nodesets的capabilities列表落实capabilities [vault, cron, http-action, http-trigger, consensus, don-time, evm-1337, evm-2337]注意evm被拆成evm-1337与evm-2337两个粒度条目分别对应两条链。两个 DON 的角色与资源分配bootstrap-gateway引导 网关合一Typesbootstrap,gatewayNodes1Rolesbootstrap,gatewayEVM chains1337,2337Exposes remote capabilitiesfalse配置中对应节点集[[nodesets]] nodes 1 name bootstrap-gateway don_family test-don-family don_types [bootstrap, gateway] override_mode each http_port_range_start 10300 env_vars { CL_EVM_CMD , OTEL_SERVICE_NAME chainlink-node } supported_evm_chains [1337, 2337] [nodesets.db] image postgres:12.0 port 13200 [[nodesets.node_specs]] roles [bootstrap, gateway] [nodesets.node_specs.node] docker_ctx ../../../.. docker_file core/chainlink.Dockerfile docker_build_args { CL_IS_PROD_BUILD false } # 5002 is the web API capabilities port for incoming requests # 15002 is the vault port for incoming requests custom_ports [5002:5002,15002:15002] user_config_overrides 要点单个节点同时扮演 P2P 引导节点与网关角色custom_ports显式暴露了 5002web API capabilities 入站端口与 15002vault 入站端口override_mode each表示配置覆盖按每个节点单独应用每个节点集自带独立 PostgreSQL 实例镜像postgres:12.0。与基础版 workflow-gateway-don.toml 相比端口起始值从 10100 调整为 10300http_port_range_start且去掉了CL_CRE_SETTINGS环境变量与p2p_port_range_start。workflow承载全部能力的执行集群TypesworkflowNodes4RolespluginEVM chains1337,2337Exposes remote capabilitiesfalse配置中对应节点集[[nodesets]] nodes 4 name workflow don_family test-don-family don_types [workflow] override_mode all http_port_range_start 10100 env_vars { CL_EVM_CMD , OTEL_SERVICE_NAME chainlink-node } capabilities [vault, cron, http-action, http-trigger, consensus, don-time, evm-1337, evm-2337] registry_based_launch_allowlist [cron-trigger1.0.0, dontime1.0.0] [nodesets.db] image postgres:12.0 port 13000 [[nodesets.node_specs]] roles [plugin] [nodesets.node_specs.node] docker_ctx ../../../.. docker_file core/chainlink.Dockerfile docker_build_args { CL_IS_PROD_BUILD false } # image chainlink-tmp:latest user_config_overrides # Configure gRPC additional workflow source # The mock server runs on port 8544 (started by the test before environment setup) [[Capabilities.WorkflowRegistry.AdditionalSources]] URL host.docker.internal:8544 TLSEnabled false Name mock-private-registry 要点4 个节点组成一个 workflow 执行集群角色统一为plugin。registry_based_launch_allowlist只放行了两个基于注册表启动的本地能力cron-trigger1.0.0与dontime1.0.0其余能力vault、http-action、http-trigger、consensus、evm通过其他方式启动。docker_ctx ../../../..与docker_file core/chainlink.Dockerfile表明节点镜像从仓库根目录构建 Chainlink 核心镜像CL_IS_PROD_BUILD false走非生产构建路径。节点级user_config_overrides是本拓扑与基础版的最大区别它在每个 workflow 节点的 Chainlink TOML 中注入 gRPC 附加工作流源配置见下一节。两条 Anvil 区块链chain_id 1337 与 2337由[[blockchains]]定义均以-b 0.50.5 秒出块间隔与--mixed-mining参数启动2337 链显式占用端口 8546[[blockchains]] type anvil chain_id 1337 container_name anvil-1337 docker_cmd_params [-b, 0.5, --mixed-mining] [[blockchains]] type anvil chain_id 2337 container_name anvil-2337 port 8546 docker_cmd_params [-b, 0.5, --mixed-mining]核心差异gRPC 附加工作流源AdditionalSources本拓扑专门用于验证「工作流元数据从 gRPC 服务加载」这一路径配置文件开头的注释说明了设计意图该拓扑与workflow-gateway-don.toml相同但AdditionalSources被配置为从host.docker.internal:8544的 gRPC 源读取工作流。被 system-tests/tests/smoke/cre/grpc_source_test.go 使用。配置语法与字段说明注入到每个 workflow 节点的覆盖片段[[Capabilities.WorkflowRegistry.AdditionalSources]] URL host.docker.internal:8544 TLSEnabled false Name mock-private-registry字段含义依据 core/config/toml/types.go 中AdditionalWorkflowSource结构体字段类型说明默认行为URLstringgRPC 服务地址host:port空字符串TLSEnabledbool是否启用 TLS 加密连接未设置时默认开启GetTLSEnabled()返回trueNamestring人类可读名称用于日志输出空字符串源码注释明确AdditionalWorkflowSource允许工作流从链上注册合约以外的来源加载例如 gRPC 服务这正是本拓扑的用途。由于本地 mock 服务不启用 TLS覆盖片段必须显式写TLSEnabled false——漏掉这一行会导致节点尝试 TLS 握手而连接失败这是排障时最容易被忽略的坑。同一字段的「正式配置」示例见 core/services/chainlink/testdata/config-full.toml[[Capabilities.WorkflowRegistry.AdditionalSources]] URL localhost:50051 TLSEnabled true Name test-grpc-source源码侧如何被消费从源码结构看附加源列表的消费链路如下AdditionalSources数组在 TOML 层被解析进WorkflowRegistry.AdditionalSourcesConfigcore/config/toml/types.goWorkflowRegistry.AdditionalSources()将 TOML 结构转换为[]config.AdditionalWorkflowSource接口core/config/toml/types.go运行时由 core/services/chainlink/config_capabilities.go 的capabilitiesWorkflowRegistry.AdditionalSources()逐条取出供工作流注册表同步器workflow registry syncer拉取元数据。也就是说链上合约注册表仍是默认来源AdditionalSources是叠加在它之上的补充元数据源代码注释中的 additional 一词即此意。测试代码中「gRPC 源操作不影响合约源工作流」的隔离断言见下文也从侧面印证了二者是并行、独立的源。平台相关的地址转换测试文件注释提供了一个重要实现细节配置中的host.docker.internal并非直接使用而是由配置生成代码在部署时自动转换为平台相关的 Docker 宿主地址例如 Linux 上为172.17.0.1从而保证无论开发机是 macOSDocker Desktop 支持host.docker.internal还是 Linux需要显式映射节点容器都能访问到宿主机上运行的 mock gRPC 服务。用冒烟测试验证 gRPC 源工作流全生命周期本拓扑被 system-tests/tests/smoke/cre/grpc_source_test.go 直接使用是验证该拓扑行为的最权威依据。测试文件定义了两个用例用例一生命周期测试Test_CRE_GRPCSource_Lifecycle验证 gRPC 附加源下工作流的完整生命周期部署、暂停、恢复、删除。执行顺序对应ExecuteGRPCSourceLifecycleTest启动 mock gRPC 服务默认端口 8544须在环境搭建之前完成因为节点配置里写死的地址就是它通过t_helpers.SetupTestEnvironmentWithConfig(t, t_helpers.GetTestConfig(t, /configs/workflow-gateway-don-grpc-source.toml))拉起本拓扑编译工作流复用core/scripts/cre/environment/examples/workflows/cron/main.go计算工作流 ID 并拷贝到容器通过 mock 服务的私有注册表 API 依次执行DeployAddWorkflow→ 等待WorkflowActivated事件PauseUpdateWorkflow(Paused: true)→ 等待WorkflowPaused事件ResumeUpdateWorkflow(Paused: false)→ 等待WorkflowActivated事件DeleteDeleteWorkflow→ 等待WorkflowDeleted事件。事件监听基于 CHiP sinkstartWorkflowEventSink每个断言超时均取同步器轮询间隔的两倍2 * grpcSourceTestSyncerInterval即 30 秒因为工作流注册表同步器syncer按固定间隔轮询源。grpcSourceTestSyncerInterval 15 * time.Second与注释中「default syncer poll interval」一致这表明源更新后最多需要约一个轮询周期才会被节点感知——调试时请务必考虑到这一延迟。生命周期测试还预留了可选的「合约源隔离检查」contractWorkflowName非空时触发每次对 gRPC 工作流执行操作后都验证合约源工作流仍然执行、节点健康无崩溃从而证明两种来源互不干扰。用例二认证拒绝测试Test_CRE_GRPCSource_AuthRejection验证当 gRPC 源拒绝 JWT 认证时mock 服务以RejectAllAuth: true启动节点能优雅处理添加工作流后等待两个同步周期断言不会收到WorkflowActivated事件assertNoWorkflowActivated随后对所有节点执行健康检查确认没有 panic 或崩溃assertNodesHealthy只对failing状态告警、不直接失败。这说明即使认证失败节点也不会崩溃注册表同步器具备容错能力。本地运行方式cd system-tests/tests go test -timeout 20m -run ^Test_CRE_GRPCSource_Lifecycle$ ./smoke/cre/...注意源码中Test_CRE_GRPCSource_Lifecycle当前带t.Skip注释原因是 gRPC 源测试依赖 V2 工作流注册表同步器CI 环境存在差异需进一步调查读者在本地复跑时应先了解这一前提认证拒绝用例则面向已预先启动的 CRE 环境go run . env start --with-chip-ingress-stack。启动整个本地环境按 core/scripts/cre/environment/README.md 的快速开始指引环境整体启动与工作流部署命令为cd core/scripts/cre/environment go run . env start --auto-setup go run . workflow deploy -w ./examples/workflows/v2/cron/main.go --compile -n cron_example--auto-setup会执行自动配置含数据库、密钥等初始化然后按所选拓扑的 TOML 拉起全部容器。若要显式指定本拓扑对应的环境可参考environment目录下的env start相关参数与 setup.toml、capability_defaults.toml 等配套文件。拓扑文档本身是可验证的真相来源任何拓扑配置的变更都需要回到environment目录执行go run . topology generate或--check校验使文档重新同步。与其他拓扑的关系与 workflow-gateway-don.toml 相比DON 结构、能力矩阵、链配置完全相同唯一差异是 workflow 节点注入了AdditionalSources覆盖片段因此端口号从 10000/10100 平移为 10100/10300 以避免与基础版并存时冲突。与 Solana/Aptos/Stellar 变体如 workflow-don-solana.toml相比本拓扑是纯 EVM 双链1337、2337环境。与 sharded 类拓扑sharded类最多 7 个 DON相比本拓扑为单 DON 家族single-don类规模最小适合作为 gRPC 源功能验证的隔离环境。在 docs/TOPOLOGIES.md 中它登记为Class: single-don、2 个 DON与 10 个兄弟拓扑共同构成 CRE 本地环境的拓扑矩阵供开发者按场景EVM 多链、gRPC 源、缓存测试、分片等选择。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Chainlink CRE 本地环境拓扑：workflow-gateway-don-grpc-source 的 gRPC 附加工作流源实战指南
Chainlink CRE 本地环境拓扑workflow-gateway-don-grpc-source 的 gRPC 附加工作流源实战指南【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink本文档面向需要在本地搭建 Chainlink CREChainlink Runtime Environment开发环境的开发者深入剖析workflow-gateway-don-grpc-source这一单 DONsingle-don类拓扑它由 1 个bootstrap-gateway节点与 4 个workflow节点组成并通过Capabilities.WorkflowRegistry.AdditionalSources配置将工作流元数据的来源从链上注册合约扩展到本地 gRPC 服务host.docker.internal:8544。读完本文你将掌握该拓扑的配置逐项含义、gRPC 附加源的配置语法与源码级实现原理以及如何用仓库中的冒烟测试验证工作流的部署、暂停、恢复与删除全生命周期。拓扑概览一条配置、两个 DON、三类职责该拓扑的官方定义位于 core/scripts/cre/environment/docs/topologies/workflow-gateway-don-grpc-source.md其对应的真实配置文件为 core/scripts/cre/environment/configs/workflow-gateway-don-grpc-source.toml。文档元数据给出了三个关键标识Configconfigs/workflow-gateway-don-grpc-source.tomlClasssingle-donInfradocker「Class: single-don」表示这是一类「单一 DON 家族」拓扑其下所有节点共享同一个don_family本例为test-don-family。在 docs/TOPOLOGIES.md 生成的总览表中它与其他 10 个拓扑并列登记DON 数为 2。该总览文件由go run . topology generate自动生成因此如果要快速在终端查看可用拓扑官方建议执行cd core/scripts/cre/environment go run . topology list底层实现位于 core/scripts/cre/environment/environment/topology.godiscoverTopologies()会递归扫描configs/目录下所有 TOML凡同时包含blockchains、nodesets、jd、infra四个节见topologyProbe结构与isTopologyConfig()即被识别为拓扑配置随后topology generate为每个配置生成对应的 Markdown 文档并写入docs/topologies/。这也解释了为什么该拓扑文档与workflow-gateway-don.md的骨架几乎一致——差异全部体现在配置内容上。Capability Matrix能力矩阵是能力归属的真相来源文档中的能力矩阵Capability Matrix是「按 DON 放置能力」的权威依据本拓扑的完整矩阵如下Capabilitybootstrap-gatewayworkflowconsensus-localcron-localdon-time-localevm-local (1337,2337)http-action-localhttp-trigger-localvault-local解读要点全部 7 类能力共识、定时任务、DON 时间、EVM、HTTP 动作、HTTP 触发、Vault都以local模式挂载在workflowDON 上即由 DON 内节点本地运行、通过 DON 内部消息传递发现而非通过网关从远程暴露。evm能力标注为local (1337,2337)对应拓扑中两个 Anvil 链的 chain_id。bootstrap-gateway不承载任何能力其职责是提供 P2P 引导bootstrap与外部流量入口gateway。这一矩阵与 workflow-gateway-don.md无 gRPC 源的姊妹拓扑完全相同说明引入 gRPC 附加源不改变能力分布只改变工作流元数据的获取路径。能力到 DON 的映射在配置中由nodesets的capabilities列表落实capabilities [vault, cron, http-action, http-trigger, consensus, don-time, evm-1337, evm-2337]注意evm被拆成evm-1337与evm-2337两个粒度条目分别对应两条链。两个 DON 的角色与资源分配bootstrap-gateway引导 网关合一Typesbootstrap,gatewayNodes1Rolesbootstrap,gatewayEVM chains1337,2337Exposes remote capabilitiesfalse配置中对应节点集[[nodesets]] nodes 1 name bootstrap-gateway don_family test-don-family don_types [bootstrap, gateway] override_mode each http_port_range_start 10300 env_vars { CL_EVM_CMD , OTEL_SERVICE_NAME chainlink-node } supported_evm_chains [1337, 2337] [nodesets.db] image postgres:12.0 port 13200 [[nodesets.node_specs]] roles [bootstrap, gateway] [nodesets.node_specs.node] docker_ctx ../../../.. docker_file core/chainlink.Dockerfile docker_build_args { CL_IS_PROD_BUILD false } # 5002 is the web API capabilities port for incoming requests # 15002 is the vault port for incoming requests custom_ports [5002:5002,15002:15002] user_config_overrides 要点单个节点同时扮演 P2P 引导节点与网关角色custom_ports显式暴露了 5002web API capabilities 入站端口与 15002vault 入站端口override_mode each表示配置覆盖按每个节点单独应用每个节点集自带独立 PostgreSQL 实例镜像postgres:12.0。与基础版 workflow-gateway-don.toml 相比端口起始值从 10100 调整为 10300http_port_range_start且去掉了CL_CRE_SETTINGS环境变量与p2p_port_range_start。workflow承载全部能力的执行集群TypesworkflowNodes4RolespluginEVM chains1337,2337Exposes remote capabilitiesfalse配置中对应节点集[[nodesets]] nodes 4 name workflow don_family test-don-family don_types [workflow] override_mode all http_port_range_start 10100 env_vars { CL_EVM_CMD , OTEL_SERVICE_NAME chainlink-node } capabilities [vault, cron, http-action, http-trigger, consensus, don-time, evm-1337, evm-2337] registry_based_launch_allowlist [cron-trigger1.0.0, dontime1.0.0] [nodesets.db] image postgres:12.0 port 13000 [[nodesets.node_specs]] roles [plugin] [nodesets.node_specs.node] docker_ctx ../../../.. docker_file core/chainlink.Dockerfile docker_build_args { CL_IS_PROD_BUILD false } # image chainlink-tmp:latest user_config_overrides # Configure gRPC additional workflow source # The mock server runs on port 8544 (started by the test before environment setup) [[Capabilities.WorkflowRegistry.AdditionalSources]] URL host.docker.internal:8544 TLSEnabled false Name mock-private-registry 要点4 个节点组成一个 workflow 执行集群角色统一为plugin。registry_based_launch_allowlist只放行了两个基于注册表启动的本地能力cron-trigger1.0.0与dontime1.0.0其余能力vault、http-action、http-trigger、consensus、evm通过其他方式启动。docker_ctx ../../../..与docker_file core/chainlink.Dockerfile表明节点镜像从仓库根目录构建 Chainlink 核心镜像CL_IS_PROD_BUILD false走非生产构建路径。节点级user_config_overrides是本拓扑与基础版的最大区别它在每个 workflow 节点的 Chainlink TOML 中注入 gRPC 附加工作流源配置见下一节。两条 Anvil 区块链chain_id 1337 与 2337由[[blockchains]]定义均以-b 0.50.5 秒出块间隔与--mixed-mining参数启动2337 链显式占用端口 8546[[blockchains]] type anvil chain_id 1337 container_name anvil-1337 docker_cmd_params [-b, 0.5, --mixed-mining] [[blockchains]] type anvil chain_id 2337 container_name anvil-2337 port 8546 docker_cmd_params [-b, 0.5, --mixed-mining]核心差异gRPC 附加工作流源AdditionalSources本拓扑专门用于验证「工作流元数据从 gRPC 服务加载」这一路径配置文件开头的注释说明了设计意图该拓扑与workflow-gateway-don.toml相同但AdditionalSources被配置为从host.docker.internal:8544的 gRPC 源读取工作流。被 system-tests/tests/smoke/cre/grpc_source_test.go 使用。配置语法与字段说明注入到每个 workflow 节点的覆盖片段[[Capabilities.WorkflowRegistry.AdditionalSources]] URL host.docker.internal:8544 TLSEnabled false Name mock-private-registry字段含义依据 core/config/toml/types.go 中AdditionalWorkflowSource结构体字段类型说明默认行为URLstringgRPC 服务地址host:port空字符串TLSEnabledbool是否启用 TLS 加密连接未设置时默认开启GetTLSEnabled()返回trueNamestring人类可读名称用于日志输出空字符串源码注释明确AdditionalWorkflowSource允许工作流从链上注册合约以外的来源加载例如 gRPC 服务这正是本拓扑的用途。由于本地 mock 服务不启用 TLS覆盖片段必须显式写TLSEnabled false——漏掉这一行会导致节点尝试 TLS 握手而连接失败这是排障时最容易被忽略的坑。同一字段的「正式配置」示例见 core/services/chainlink/testdata/config-full.toml[[Capabilities.WorkflowRegistry.AdditionalSources]] URL localhost:50051 TLSEnabled true Name test-grpc-source源码侧如何被消费从源码结构看附加源列表的消费链路如下AdditionalSources数组在 TOML 层被解析进WorkflowRegistry.AdditionalSourcesConfigcore/config/toml/types.goWorkflowRegistry.AdditionalSources()将 TOML 结构转换为[]config.AdditionalWorkflowSource接口core/config/toml/types.go运行时由 core/services/chainlink/config_capabilities.go 的capabilitiesWorkflowRegistry.AdditionalSources()逐条取出供工作流注册表同步器workflow registry syncer拉取元数据。也就是说链上合约注册表仍是默认来源AdditionalSources是叠加在它之上的补充元数据源代码注释中的 additional 一词即此意。测试代码中「gRPC 源操作不影响合约源工作流」的隔离断言见下文也从侧面印证了二者是并行、独立的源。平台相关的地址转换测试文件注释提供了一个重要实现细节配置中的host.docker.internal并非直接使用而是由配置生成代码在部署时自动转换为平台相关的 Docker 宿主地址例如 Linux 上为172.17.0.1从而保证无论开发机是 macOSDocker Desktop 支持host.docker.internal还是 Linux需要显式映射节点容器都能访问到宿主机上运行的 mock gRPC 服务。用冒烟测试验证 gRPC 源工作流全生命周期本拓扑被 system-tests/tests/smoke/cre/grpc_source_test.go 直接使用是验证该拓扑行为的最权威依据。测试文件定义了两个用例用例一生命周期测试Test_CRE_GRPCSource_Lifecycle验证 gRPC 附加源下工作流的完整生命周期部署、暂停、恢复、删除。执行顺序对应ExecuteGRPCSourceLifecycleTest启动 mock gRPC 服务默认端口 8544须在环境搭建之前完成因为节点配置里写死的地址就是它通过t_helpers.SetupTestEnvironmentWithConfig(t, t_helpers.GetTestConfig(t, /configs/workflow-gateway-don-grpc-source.toml))拉起本拓扑编译工作流复用core/scripts/cre/environment/examples/workflows/cron/main.go计算工作流 ID 并拷贝到容器通过 mock 服务的私有注册表 API 依次执行DeployAddWorkflow→ 等待WorkflowActivated事件PauseUpdateWorkflow(Paused: true)→ 等待WorkflowPaused事件ResumeUpdateWorkflow(Paused: false)→ 等待WorkflowActivated事件DeleteDeleteWorkflow→ 等待WorkflowDeleted事件。事件监听基于 CHiP sinkstartWorkflowEventSink每个断言超时均取同步器轮询间隔的两倍2 * grpcSourceTestSyncerInterval即 30 秒因为工作流注册表同步器syncer按固定间隔轮询源。grpcSourceTestSyncerInterval 15 * time.Second与注释中「default syncer poll interval」一致这表明源更新后最多需要约一个轮询周期才会被节点感知——调试时请务必考虑到这一延迟。生命周期测试还预留了可选的「合约源隔离检查」contractWorkflowName非空时触发每次对 gRPC 工作流执行操作后都验证合约源工作流仍然执行、节点健康无崩溃从而证明两种来源互不干扰。用例二认证拒绝测试Test_CRE_GRPCSource_AuthRejection验证当 gRPC 源拒绝 JWT 认证时mock 服务以RejectAllAuth: true启动节点能优雅处理添加工作流后等待两个同步周期断言不会收到WorkflowActivated事件assertNoWorkflowActivated随后对所有节点执行健康检查确认没有 panic 或崩溃assertNodesHealthy只对failing状态告警、不直接失败。这说明即使认证失败节点也不会崩溃注册表同步器具备容错能力。本地运行方式cd system-tests/tests go test -timeout 20m -run ^Test_CRE_GRPCSource_Lifecycle$ ./smoke/cre/...注意源码中Test_CRE_GRPCSource_Lifecycle当前带t.Skip注释原因是 gRPC 源测试依赖 V2 工作流注册表同步器CI 环境存在差异需进一步调查读者在本地复跑时应先了解这一前提认证拒绝用例则面向已预先启动的 CRE 环境go run . env start --with-chip-ingress-stack。启动整个本地环境按 core/scripts/cre/environment/README.md 的快速开始指引环境整体启动与工作流部署命令为cd core/scripts/cre/environment go run . env start --auto-setup go run . workflow deploy -w ./examples/workflows/v2/cron/main.go --compile -n cron_example--auto-setup会执行自动配置含数据库、密钥等初始化然后按所选拓扑的 TOML 拉起全部容器。若要显式指定本拓扑对应的环境可参考environment目录下的env start相关参数与 setup.toml、capability_defaults.toml 等配套文件。拓扑文档本身是可验证的真相来源任何拓扑配置的变更都需要回到environment目录执行go run . topology generate或--check校验使文档重新同步。与其他拓扑的关系与 workflow-gateway-don.toml 相比DON 结构、能力矩阵、链配置完全相同唯一差异是 workflow 节点注入了AdditionalSources覆盖片段因此端口号从 10000/10100 平移为 10100/10300 以避免与基础版并存时冲突。与 Solana/Aptos/Stellar 变体如 workflow-don-solana.toml相比本拓扑是纯 EVM 双链1337、2337环境。与 sharded 类拓扑sharded类最多 7 个 DON相比本拓扑为单 DON 家族single-don类规模最小适合作为 gRPC 源功能验证的隔离环境。在 docs/TOPOLOGIES.md 中它登记为Class: single-don、2 个 DON与 10 个兄弟拓扑共同构成 CRE 本地环境的拓扑矩阵供开发者按场景EVM 多链、gRPC 源、缓存测试、分片等选择。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考