[Bug] 修正 URMA 资源生命周期 #2787

收尾与范围拆分： 生命周期修复已由 #2835 合并交付（cae0f728df00bbf77eb058815d71afaaee284af8）。按确认的范围拆分关闭本 issue：ISA manager 内部释放错误不可见、失败资源记录保留及 ISA 支持后的 simpler 接入/验收，转由 #2885（simpler 仓） 独立跟踪。关闭不表示该 ISA 限制已修复。下文保留原始问题、设计讨论与验收清单作为历史依据。

Platform

a5 (Ascend 950 hardware)

Runtime Variant

tensormap_and_ringbuffer

Description

以已核对的 simpler main fb63f4c02220ed99a70150409c676711dcdbb418、PTO-ISA pin 217bb98952a8f9004b95fe938da97d8d5f68f702 为分析基线，修正 A5 TMR Device URMA 在正常释放、部分初始化失败和销毁失败时的资源所有权及释放顺序。

目标是：任何仍可能被 kernel、网络请求或 HCCL 注册/channel 引用的 workspace、notify pool、通信窗口和上下文，都必须存活到其使用方退出并解除引用；无法证明安全释放时，失败应可见，资源仍有明确 owner。

整体问题与设计目标：

L1–L4 是同一生命周期缺口在不同路径上的表现：资源跨越 Worker、基础 communicator 和 domain，多层接口对“拥有、借用、初始化提交、释放完成”的含义尚未形成一致契约。本 issue 应先梳理完整调用链和依赖关系，再调整初始化、失败回滚、domain release 与 finalize；不以局部移动 reset/free 或把所有资源延后到 Worker 退出作为最终方案。

• 创建进程保有实际生命周期责任。 L3/L4 负责逻辑 domain 和跨进程协调；L2 ChipWorker 的 host 进程创建本地 ACL/HCCL/内存对象，并执行实际销毁。借用方只能使用资源、报告完成或错误，不能擅自释放拥有方资源；父进程收到错误后协调 owner 收尾，不能直接销毁子进程私有句柄。
• 区分独占资源与共享借用。 资源账本要列出创建/释放接口、owner、使用者、依赖、释放前置条件和失败后的持有者。首次 allocate_domain 时惰性创建的共享 workspace 不自动成为该 domain 私有资源；释放 domain 应回收其自有资源并撤销共享借用。
• 按依赖关系逆序释放。 通常先申请后释放、后申请先释放，但必须以实际引用关系为准；不能仅靠创建时间排序。先停止新使用并确认执行/网络完成，再解除外部通信引用，最后释放被引用的内存和对象。
• 初始化也是完整生命周期的一部分。 第一笔资源取得时就必须有 owner，每一步成功立即登记；全部成功才发布 domain。失败回滚沿同一资源记录执行，尚不能安全回收的部分仍有 owner，错误逐层返回。未完成初始化不能无条件进入要求所有成员均已就绪的正常 collective 释放流程。

现有流程中应保留的行为：

公开 domain release 可能先撤销逻辑使用资格，并在已有 run 尚未退休时登记 pending release；待对应 run fence 确认完成后再执行物理回收，这是合理的使用期保护。Worker close 应在子进程控制通道仍可用时协调 domain 清理，再收尾共享通信资源及设备环境。应沿用已有 run fence、cleanup journal、回收 guard 和层级关闭机制，补足它们与 backend 结果的衔接。

主线可确认的问题与证据边界：

已有保护必须保留：

主线 ChipWorker::comm_release_domain_windows() / comm_destroy() 已调用 require_comm_reclamation_safe()，检查 unconfirmed reclamation、poisoned run lane 和未证明结束的 native run。因此本 issue 不声称主线完全没有停止/回收保护，也不凭 backend 局部代码断言支持的公开路径一定能在 active kernel 中释放资源。应复用现有运行与失败收尾状态，补足 URMA 的网络/注册资源生命周期证明。

Steps to Reproduce

本 issue 当前基于源码核对与旧 PR 的问题/测试场景提交；本次未新增上述 main/pin 组合的上板故障复现。

1. 对照 L1 的 backend 销毁顺序与实际 ISA Finalize 前置条件，核对 manager、notify pool、窗口、HCCL 注册及 channel 的引用关系。
2. 检查 L2 的 domain release：分别分析 barrier 成功/失败、已完成请求和未确认状态；把 ChipWorker 现有安全检查纳入完整调用链。
3. 在生产初始化/释放路径上注入阶段失败：notify pool 分配后、部分内存注册后、channel 获取后、workspace/context 发布前后，以及 HCCL 销毁或相关同步失败。记录每次保留、注销、Finalize、free/unmap 和 owner 释放的顺序。
4. 在 A5DT 使用当前 pin 的独立 URMA 构建，通过 pytest 验证正常完成后的显式通信销毁、domain 释放/再次分配，以及重复运行/关闭。模拟故障和 32 位边界的 CPU 注入结果不能代替硬件故障复现；不需要为此在共享设备上强行制造 driver/HCCL 故障。

Expected Behavior

• 明确 workspace/notify pool、注册内存、channel、device context、local/peer windows、communicator 和 caller-owned stream 的 owner 及依赖关系，覆盖正常和异常路径。
• 成功释放有足够的停止/完成与解除注册引用证据：停止新提交、确认执行和相关网络请求结束、解除通信资源引用之后，才 Finalize/free/unmap。网络 drain 依据应与 [Bug] 修正当前 ISA 下的 URMA 提交与完成协议 #2775 的实际 BB/CQE/错误语义一致，不能继续采用旧版单行/单 jetty 假设。
• 保留并复用现有 ChipWorker 回收安全检查及 native run 失败收尾；不增加可绕过这些检查的另一条释放路径。
• 各部分 Init 失败阶段的已创建资源仍有明确 owner；只有确实无外部引用的资源可以立即清理；已建立注册/channel 的资源遵守相应销毁顺序。
• domain release 的逻辑撤销、等待在途使用、物理回收完成、清理失败均有明确语义。正常物理回收不依赖 Worker 退出；只有必要的不确定资源才能保留，并明确 owner、收尾边界、资源代价和 allocation ID 复用规则。
• 同一 Worker 内重复 allocate/release 后，domain 自有资源回到创建前水平，共享资源有独立且稳定的计账；释放 domain A 不影响仍在使用的 domain B 和基础 communicator。
• stop/drain/注销或 HCCL destroy 失败时，返回可观察错误并保留仍需保留的资源及 owner；后续 close/异常析构/对象销毁不会提前 free 或双重释放。复用既有不确定资源保留机制，或给出必要的新策略及资源代价；不默认要求永久 quarantine。
• 从 backend 到 ChipWorker/Python 的错误与所有权转移一致；不在 backend 仍需持有资源时无条件忘记唯一 handle。重复 close/release、部分成功后再次收尾的实际支持行为有测试和文档。
• 故障注入覆盖 L1–L4 的生产路径和现有回收 guard，验证操作顺序与恰好一次释放；不能仅用源码字符串检查或独立 helper 的测试代替调用链验证。
• A5DT 本地 URMA=ON 验证记录真实源码、ISA pin、构建/加载产物和 pytest 执行结果；明确 normal lifecycle 与故障注入的不同证据范围。保留 SDMA/URMA=OFF 配置的回归覆盖；与 [Feature] 分离 SDMA、URMA、RDMA workspace，支持多通信后端共存 #2739/Refactor: separate SDMA, URMA and RDMA workspaces #2790 协调 URMA=ON CI 接入，避免覆盖或撤销其共存与测试配置。正常传输通过不能替代生命周期失败路径验收。

建议实施顺序：

1. 列出 Worker / communicator / domain 资源账本和完整调用链，核对每个 backend 接口的真实语义；本 issue 的实现范围仍是 A5 URMA 及其必要公共衔接。
2. 核实最终实现基线的 HCCL/ISA 注册、channel 释放与错误契约。可独立注销则由 domain owner 执行；只能随共享 communicator 销毁则需设计独立生命周期边界，先明确所需能力和依赖，不能只延长 backing 存活期后宣称完成 L2。
3. 建立从首次资源取得开始的初始化事务；提交、部分回滚、正常关闭共用资源记录和依赖规则，避免不同 catch/析构/finalize 各维护一套清理逻辑。
4. 提供可报告失败的显式收尾路径，传播到 ChipWorker/Python。每阶段区分已释放、尚未释放和状态不确定；仅在契约允许时重试，不能把重复 close 一律变成盲目重试，也不能让析构重新触发危险释放。
5. 按依赖协调 finalize：停止接收新工作，确认使用者退出，回收 domain，再释放共享通信资源，最后退出设备环境。某阶段失败是否允许继续执行后续阶段，应由依赖和 API 错误语义决定。
6. 故障注入须使用真实 manager 配合有状态的 HCCL mock，覆盖部分注册/channel 建立、上下文发布、逐阶段清理失败和上层错误传播；仅替换 manager 的 host fixture 无法证明真实注册生命周期。保留 L1–L4 作为完整设计的验收场景。

Actual Behavior

当前源码存在 L1–L4 的顺序/所有权问题或待补全契约。正常销毁与部分初始化失败路径可以在 HCCL 通信资源销毁前 Finalize manager 或释放 backing；domain release 与异常关闭也尚需明确何时可以物理回收，以及失败后的 owner 如何保留。

主线已有执行资源回收 guard；本 issue 不把它描述为不存在，也不将旧版本的测试结果或 a2a3 SDMA 的故障清理现象当成当前 A5 URMA 已上板复现。

Git Commit ID

fb63f4c

Host Platform

Linux (aarch64)

Additional Context

问题来源：

• Fix: align A5 URMA completion and resource lifetime contracts #2675，原 head cd5e26f0d9ace8a5d96bae05a5875e1c4cdd9291：stop/drain/destroy 后再释放、部分初始化失败资源保留、逻辑 release、销毁失败隔离等问题分析和生命周期回归场景。作为参考，不要求原样采用其永久 quarantine、单队列假设或 domain 子 communicator 方案；旧 base/pin 验证不替代当前修订验收。
• Refactor(comm): consume the decoupled pto-isa async workspace and completion records #2650 的 部分初始化失败所有权评审，原 head e22f05a79837f587e0c99da9c7af429f48210ca6。该评审原本针对 a2a3 SDMA facade 迁移，只作为公共接口生命周期风险的相关证据，不能写成 A5 URMA 已复现故障。相关 a2a3 故障清理问题见 [Performance] Provisioning the PTO-ISA async-SDMA workspace degrades AICore fault recovery ~1000x (0.3s → ~306s) on a2a3 #1425。

ISA 支持与责任边界：

当前 pin 的 公共 workspace facade 在 URMA Init 失败时仍先 delete manager，再返回错误；外层 AbandonWorkspace 无法撤销该析构。主线直接 manager 路径的局部析构属于 simpler 可修正的接入问题，不必先迁移 facade。如果后续选择公共 facade，必须核对其失败资源保留/移交契约，必要时关联独立 ISA 支持项。不预设必须修改 ISA，也不要求通过回退 pin、复制 manager 或私有覆盖头文件规避问题。

与其他工作的边界：

• Related: [Bug] 修正当前 ISA 下的 URMA 提交与完成协议 #2775（提交/事件元数据/完成协议）。本 issue 消费其 drain/失败语义，负责何时能释放资源；[Bug] 修正当前 ISA 下的 URMA 提交与完成协议 #2775 不因此重新扩展为生命周期修复。
• domain 之间的注册/channel 命名空间隔离、独立子 communicator 及并发隔离另行跟踪；如果独立 domain 回收必须依赖其中某项能力，则将其列为本 issue 的明确前置依赖，缺少该能力时不能宣称 L2 完整解决。不预设子 communicator 一定是唯一方案，也不静默扩大并发功能范围。
• Related: [Feature] 分离 SDMA、URMA、RDMA workspace，支持多通信后端共存 #2739（多后端 workspace 共存）、[Feature] 支持 URMA 多 AIV 向同一 peer 并发发送 #2673 / [Track] A5 URMA 通信：多 AIV 并发发送与编译能力暴露 #2708（URMA 并发/能力）。不在此扩大到 Host DDR、HBG 新能力、多 AIV/共享池或批量提交。
• 独立于 Refactor(comm): consume the decoupled pto-isa async workspace and completion records #2650/Fix: align A5 URMA completion and resource lifetime contracts #2675 的实现和合入状态；后续通过本 issue 关联新的实现 PR 和验收证据。创建本 issue 不表示已有问题已修复，也不关闭旧 PR。

基线与多后端工作的衔接：

#2790 当前仍是未合并 PR，负责多后端 workspace 分离；其 head 8340261cf1d7d45d4a1eddd54054b9d8eee8f59b 使用 ISA pin f83d4b7e4be0a4ca9805944ae2d9ce8c84e581f7。本文 L1–L4 的原始源码证据保留原基线，实施前须在最终选定的 simpler/ISA 组合重新核对，不能把旧 pin 结论直接当成新 pin 的已验证事实。#2790 报告的正常 URMA/混合后端传输验证不等于真实注册生命周期或失败回滚已修复；这些既有问题不表述为 #2790 新增回归。

跨后端梳理发现的 RDMA/HNS1825 清理失败所有权问题由 #2823 单独跟踪，不并入本 issue 的 URMA 实现范围。