celestialflow 3.2.3__tar.gz → 3.2.4__tar.gz

{celestialflow-3.2.3 → celestialflow-3.2.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: celestialflow
-Version: 3.2.3
+Version: 3.2.4
 Summary: A flexible GRAPH-based task orchestration framework.
 Author-email: Mr-xiaotian <mingxiaomingtian@gmail.com>
 License: MIT
@@ -19,9 +19,7 @@ Requires-Dist: fastapi
 Requires-Dist: uvicorn
 Requires-Dist: requests
 Requires-Dist: networkx
-Requires-Dist: redis
 Requires-Dist: jinja2
-Requires-Dist: celestialtree>=0.1.3
 
 # CelestialFlow ——一个轻量级、可并行、基于图结构的 Python 任务调度框架
 
@@ -39,8 +37,8 @@ Requires-Dist: celestialtree>=0.1.3
 <p align="center">
   <img src="https://img.shields.io/badge/Task%20Graph-DAG-blueviolet">
   <img src="https://img.shields.io/badge/Workflow-Orchestrator-7c3aed">
-  <img src="https://img.shields.io/badge/IPC-Redis%20Ready-red">
-  <img src="https://img.shields.io/badge/Distributed-Worker%20Friendly-orange">
+  <img src="https://img.shields.io/badge/Event%20Tracing-CelestialTree-0ea5e9">
+  <img src="https://img.shields.io/badge/Web-Dashboard-FastAPI-ec4899">
 </p>
 
 <p align="center">
@@ -73,7 +71,7 @@ TaskGraph 能构建完整的 **有向图结构（Directed Graph）**，不仅支
 
 在执行与调度之外，CelestialFlow 进一步引入 **CelestialTree（简称: ctree） 事件追踪系统**，为每一个任务及其衍生行为（成功、失败、重试、拆分、路由等）记录明确的因果关系。借助 ctree，可以从任意一个初始任务出发，完整还原其在 TaskGraph 中的传播路径与执行轨迹，使任务系统可以进行完整的**追溯、分析、解释**。
 
-在此基础上，CelestialFlow 支持 Web 可视化监控，并可通过 Redis 实现跨进程、跨设备协作；同时引入基于 Go 的外部 worker（通过 Redis 通信），用于承载 CPU 密集型任务，弥补 Python 在该场景下的性能瓶颈。
+在此基础上，CelestialFlow 支持 Web 可视化监控，并提供基于 Redis 的 demo 与 Go Worker 外部协作示例，用于展示按需构建跨进程、跨设备任务协作的方式。
 
 ## 项目结构（Project Structure）
 
@@ -136,6 +134,18 @@ uv pip install celestialflow
 pip install celestialflow
 ```
 
+如果你只使用 CelestialFlow 的核心调度、Web、持久化与 demo/test 之外的常规功能，上面的安装已经足够。
+
+如果你还需要启用 CelestialTree 事件追踪能力，则需要**额外安装** `celestialtree`：
+
+```bash
+# 对已发布包使用者
+uv pip install celestialtree
+
+# 如果你是 clone 仓库后的开发者/贡献者
+uv sync --group dev
+```
+
 一个简单的可运行代码:
 
 ```python
@@ -215,7 +225,7 @@ flowchart TD
 - [runtime/util_hash.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/runtime/util_hash.md)
 - [runtime/util_types.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/runtime/util_types.md)
 - [runtime/util_errors.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/runtime/util_errors.md)
-- [persistence/core_fail.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/persistence/core_fail.md)
+- [persistence/core_fallback.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/persistence/core_fallback.md)
 - [persistence/core_log.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/persistence/core_log.md)
 
 如果你更喜欢通过完整案例理解框架的运行方式，可以参考这篇利用 TaskGraph 从零开始构建项目的教程：
@@ -228,20 +238,20 @@ flowchart TD
 
 你可以继续运行更多的演示代码，这里记录了各个演示文件与其中的演示函数说明：
 
-[🎮demo/](https://github.com/Mr-xiaotian/CelestialFlow/tree/main/docs/zh-CN/demo)
+[🎮demo/ 总览](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/demo/README.md)
 
-​如果你想运行测试代码, 可以先查看如下文档内容:
+如果你想运行测试代码，可以先查看如下文档内容：
 
-[🧪tests/](https://github.com/Mr-xiaotian/CelestialFlow/tree/main/docs/zh-CN/tests)
+[🧪tests/ 总览](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/tests/README.md)
 
-如果你想查看bench内容, 这里的数据成为框架中部分设计的决策依据:
+如果你想查看 bench 内容，这些数据也是框架中部分设计取舍的依据：
 
-[⚡bench/](https://github.com/Mr-xiaotian/CelestialFlow/tree/main/docs/zh-CN/bench)
+[⚡bench/ 总览](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/bench/README.md)
 
 ## 环境要求（Requirements）
 
-**CelestialFlow** 基于 Python 3.12+，并依赖以下核心组件。
-请确保你的环境能够正常安装这些依赖（`pip install celestialflow` 会自动安装）。
+**CelestialFlow** 基于 Python 3.12+，默认运行时依赖以下核心组件。
+其中 `celestialtree` 不再属于默认运行时依赖，而是额外安装的可选组件。
 
 | 依赖包           | 说明 |
 | ----------------- | ---- |
@@ -252,73 +262,74 @@ flowchart TD
 | **networkx**      | 任务图（TaskGraph）结构与依赖分析 |
 | **jinja2**        | FastAPI 模板引擎，用于 Web 可视化界面渲染 |
 | **tqdm**          | 可选组件，进度条显示，用于任务执行可视化 |
-| **redis**         | 可选组件，用于分布式任务通信（`TaskRedis*` 系列模块） |
-| **celestialtree** | 可选组件，用于任务状态上报与远程调用（`ctree_client`） |
+
+如需运行 `demo/demo_redis.py` 或 Go Worker 示例，请额外安装 `redis` 并准备 Redis 服务；这部分不属于默认运行时依赖。
+
+如需运行依赖 CelestialTree 的 demo / bench / 追踪查询，请额外安装 `celestialtree`，或直接在源码仓库中执行 `uv sync --group dev`。
 
 ## 文件结构（File Structure）
 
 <p align="center">
   <img src="https://raw.githubusercontent.com/Mr-xiaotian/CelestialFlow/main/img/file_structure.svg" alt="FileStructure" />
   <br/>
-  <em>celestial-flow 3.2.3</em>
+  <em>celestial-flow 3.2.4</em>
 </p>
 
 (该视图由我的另一个项目[CelestialVault](https://github.com/Mr-xiaotian/CelestialVault)中inst_file.FileTree.print_tree()生成。转换为图片则借助[Carbon](https://carbon.now.sh)。)
 
 ## 版本日志（Version Log）
-- 3.2.3
+- 3.2.4
   - feat:
-    - **[IMPORTANT]** 前端仪表盘设置面板中新添 `节点等待使用全局估计` 开关, 开启后节点卡片中原 `等待` 量将被替换为 `全局等待`, 并在卡片中显示 `全局剩余时间`
-      - 这个功能非常有趣, 开启前后能看到数值大幅波动
-    - **[IMPORTANT]** 重写任务注入页面, 现在实用性远远高于之前版本
-      - 可以给每个节点单独配置注入任务列表, 在一起发送
-    - **[IMPORTANT]** 移除 `TaskExecutor` 中 `get_args` 与 `process_result` 两个方法, 以及 `unpack_task_args` 属性
-      - 这是为引入泛型必要的修改
-      - `process_result` 功能很简单, 对func输出的result进行再次处理, 但事实上在输入func前对齐进行包装也能达到一样的效果
-      - `get_args` 功能更为复杂, 可以直接将前一节点提供的 `result` 转为当前节点所需的 `task` 类型, 非常灵活; 但问题在于太过灵活, 导致使用心智负担很大
-      - `unpack_task_args` 就是 `get_args` 带来的一项心智负担, 默认 `get_args` 会把 `task` 进行 `(task, )` 包裹后发送给func, 开启 `unpack_task_args` 后则直接发送
-    - **[IMPORTANT]** `graph` 的init参数中添加 `name`, 以与 `executor` `stage` 一致
-      - 破坏接口破坏性更新
-      - 在日志的 `start_graph` `end_graph` 与web端的 `graph_anaylysis` 中都有显示
-    - 彻底移除前后端通信中的 `graph_summary` , 原本残余的 `全局剩余时间` 现在拆为各个节点的 `全局等待` 与 `全局剩余时间`
-      - 这里所说的 `全局` 意为根据图论关系, 由上游剩余的任务数估算下游总共能获得多少任务
-      - 例如: 图关系 `A -> B`, A已处理任务2, 未处理任务3, B已处理任务4, 未处理任务2. 这意味着A成功的2个任务为B带来总共了6个任务, 那么我们可以据此估计B总功能获取"3/2*6=9"个任务, 因此B的 `等待` 任务数量为2, 但 `全局等待` 任务数量为5
-    - 前端中添加部分提示气泡, 鼠标放上去后可以介绍相关信息, 例如本次新加入的节点 `全局等待` 的含义
-    - 移除前端中节点卡片的拖拽功能
-      - 这个功能是在最早加入web页面时添加的, 当时感觉很帅, 但现在有点玩腻了
-    - 前端错误日志页面添加 `任务注入` 按钮, 可以把选定任务直接添加到任务注入页面中节点的代注入任务列表中
-    - 在 `TaskSplitter` 中添加 `split_item` 方法, 可自由定义
-      - 原本的 `splitter` 非常依赖于 `get_args`, 现在通过 `split_item` 方法稍微弥补其缺失的灵活性
+    - **[IMPORTANT]** 合并原有的 `fail_funnel` 与 `success_funnel` 机制为 `fallback` , 并采用 `sqlite` 进行存储
+      - 原有基于 `jsonl` 存储的fail持久化机制在存储时非常好用, 但读取时每次都需要全量读取到内存中再进行检索, 非常麻烦; 我虽然也想过用类似 `redis` 的数据库服务, 但实在不想另外启动第三方服务. 然后我意外发现 `sqlite` 完美符合我的一切要求
+      - Richard 万岁!
+      - 至于原有的 `success_funnel` 机制完全是个半成品: 只能用于 `executor`, 而不能用于 `stage`; 完全在内存存储. 所以借着这次机会也一并重构, 合并入 `fallback_funnel`
+      - 现在 `fallback_funnel` 会在任务 `注入/重复/重试/失败/成功` 时对sqlite中相应记录进行插入/更新/删除操作
+      - 其中在任务成功时默认会删除该条记录, 但如果开启 `executor` 中的 `perist_result` 选项, 则会保留该条记录, 并将 `status` 字段更新为 `success`
+    - **[IMPORTANT]** 移除 `stages` 中的三个redis节点, 并添加demo文件, 说明如果自行构建相关节点
+      - 相比 `TaskSplitter` 与 `TaskRouter`, 这三个节点实在可有可无, 还会导致多一个 `redis` 依赖包
+    - **[IMPORTANT]** `celestialtree` 不再继续作为依赖库, 现有的事件声明机制基于一套protol接口, 并默认使用本地的超简化实现
+      - 这样做同样是为了避免太多库依赖, `celestialtree` 库包含对 `grpcio` 与 `protobuf` 的依赖, 而这两者对于python free-threading版本的支持性不太好, 因此在有他们的情况下 `celestialflow` 无法在free-threading版本下运行----而这是我非常期待的
+      - 根据 `bench_gil_vs_nogil`, 在free-threading版本下, `executor` 在cpu密集任务中会得到5.25倍提升, 而 `graph` 在cpu密集任务中则会得到7.55倍提升. 非常喜人
+    - 在前端 `节点指标走向` 卡片中添加 `全局等待队列`
+    - 在 `graph` 中添加 `start_graph_db` 方法, 接受一个fallback数据库地址, 然后根据其中失败数据进行 `start_graph`; 在 `executor` 中添加 `start_db` 方法, 接受一个fallback数据库地址, 然后根据其中失败数据进行 `start`
+      - 很方便
   - refactor:
-    - **[IMPORTANT]** 引入泛型, 同时强制性要求py版本>=3.12
-      - 泛型的引入使得代码更加类型安全, 同时也提高了代码的可读性
-      - 3.12版本对泛型的表述非常直观
-    - 移除前端代码中所有对 `localStorage` 的使用
-      - 在已经有config配置文件的情况下意义不大, 反而会带来困扰
-    - 将任务队列的drain操作从graph层移至stage层
-      - 之前不能这样做是因为节点的 `stage_mode` 可能为 `process`, 此时在主进程持有的节点非真实运行的节点
-      - 算是3.2.0版本带来的持久影响之一
-    - 优化 `TaskMetric` 中对锁的使用
-    - 移除 `TaskEnvelope` 中的 `change_id()` 方法, 现在默认envelope不可变, 同时 `emit_retry_envelope` 中不再把原有的envelope的id修改后继续提交给worker, 而是直接使用新生成的envelope
-    - 移除错误日志中的 `error` `error_repr` `task_repr` 字段
-    - 修改前后端通信中任务注入数据的格式, 以方便同时提交多个节点的任务数据
-    - 前端代码中开启strict检查
-    - 将前端中 `injection.css` 文件拆分成多个文件
-    - 修改 `config.json` 的数据格式, 现在按照生效区域进行分类
-    - 收紧前端中的数据类型
-    - 添加 `ReportTaskGraph` 类型, 专门用于给reporter做类型声明
+    - **[IMPORTANT]** 将server端存储error数据的方式从py原生列表改为一个临时sqlite数据库
+      - 在锤子效应下我想更多的尝试sqlite的使用
+    - 为每个 `graph` 添加基于 `name` 与 `time.time()` 的 `graph_id` 作为唯一性标识符
+    - 重写reporter与server端的交互逻辑
+      - 现在每一轮refresh开始时都会进行状态对齐, 通过 `graph_id` 确定两者所持有的数据是否来自一个 `graph` 对象, 是的话则不用重复push structure/analysis数据
+      - 在状态对齐时如果双方的graph一致, server会返回自己所持有的错误数据中最大的 `event_id` 值, 经过严格校验, `event_id` 在数据库中严格递增
+      - 将reporter中原有的 `push_error_meta` 与 `push_error_content` 合并, 每次刷新时只发送新增的错误数据, 而新增数据则根据server返回的最大 `event_id` 值与本地数据库中的最大 `event_id` 值进行筛选
+    - 为 `graph.connect` 与 `graph_set_stage` 绑定更多职责
+      - 现在节点与 `graph` 在 `ctree` `reporter` 上的同步在 `graph_set_stage` 中完成
+      - 而 `task_queue` 与 `result_queue` 的上下流绑定, 以及 `counter` 的绑定都在 `graph.connect` 中完成
+    - 删除 `TaskEnvelope` 中无关数据, 只保留 `task` `hash` `id` 三项
+      - `source` 字段本就不该添加, 它一致没有发挥作用
+      - `prev` 字段是为了原版 `success_funnel` 而服务的, 现在已经没有必要
+    - `TaskMetrics` 中固定使用 `Lock` 对所有 `counter` 进行限定, 而无关乎 `executor` 的 `execution_mode`
+      - 这种固定的模式在牺牲部分性能的情况下使得代码更加稳定
+      - 根据 `bench_lock_overhead`, 这会导致 `counter` 慢3.2倍左右, 考虑到 `counter` 的更新全部基于 `int` 类型, 本就很快, 可以接受
+    - 在 `process_task_success` 中除去已有的一次 `task.success` 声明, 会在 `result_envelope` 进入 `result_queue` 前再进行 `task.input` 声明
+      - 为了保证fallback的sqlite中 `event_id` 全局统一
+    - `executor.get_fail_pairs`(原 `executor.get_error_pairs`) 会返回 `tuple[T, PeristedError]`
+      - `PeristedError` 由记录的 `error_type` 与 `error_message` 组成
+    - 重写 `TaskRouter` 节点, 现在必须传入一个 `router` 函数, 去指定任务的路由方向
+    - 移除一些没用的方法
+      - 比如 `TaskGraph.get_stage_input_trace`
   - fix:
-    - i18n本地化在部分字段上失效的问题
-    - 直接点击仪表盘中错误数字跳转到错误日志页后, 设置面板显示的还是仪表盘页面的设置
-    - 前端中为各项仪表盘请求添加 `RequestSeq`, 以避免前后发送两个请求, 但因为延迟关系, 先发送的请求的返回覆盖掉后发送请求的返回
-    - 修复前端中各项空字段需要在第一次refresh才显示的问题, 体感上会导致"加载"很慢
+    - 前端仪表盘页面中的结构图不会再因切换tab而显示空白
+      - 这是很古老的bug, 我不知道我为什么译制片没有修复
   - chore:
-    - 将文档更新翻译为英/日两语
-      - 这项操作太耗token了
+    - 添加更多demo
+    - 添加更多benchmark
+    - 添加 `Agents.md` 文件
+      - 我受够了无休止的对ai进行强调
 
 更多过往日志可看:
 
-[change_log.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/change_log.md )
+[change_log.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/change_log.md)
 
 ## Star 历史趋势（Star History）
 
@@ -327,7 +338,7 @@ flowchart TD
 ![Star History Chart](https://api.star-history.com/svg?repos=Mr-xiaotian/CelestialFlow&type=Date)
 
 ## 许可（License）
-This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
+This project is licensed under the MIT License - see the [LICENSE](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/LICENSE) file for details.
 
 ## 作者（Author）
 Author: Mr-xiaotian

{celestialflow-3.2.3 → celestialflow-3.2.4}/README.md

@@ -14,8 +14,8 @@
 <p align="center">
   <img src="https://img.shields.io/badge/Task%20Graph-DAG-blueviolet">
   <img src="https://img.shields.io/badge/Workflow-Orchestrator-7c3aed">
-  <img src="https://img.shields.io/badge/IPC-Redis%20Ready-red">
-  <img src="https://img.shields.io/badge/Distributed-Worker%20Friendly-orange">
+  <img src="https://img.shields.io/badge/Event%20Tracing-CelestialTree-0ea5e9">
+  <img src="https://img.shields.io/badge/Web-Dashboard-FastAPI-ec4899">
 </p>
 
 <p align="center">
@@ -48,7 +48,7 @@ TaskGraph 能构建完整的 **有向图结构（Directed Graph）**，不仅支
 
 在执行与调度之外，CelestialFlow 进一步引入 **CelestialTree（简称: ctree） 事件追踪系统**，为每一个任务及其衍生行为（成功、失败、重试、拆分、路由等）记录明确的因果关系。借助 ctree，可以从任意一个初始任务出发，完整还原其在 TaskGraph 中的传播路径与执行轨迹，使任务系统可以进行完整的**追溯、分析、解释**。
 
-在此基础上，CelestialFlow 支持 Web 可视化监控，并可通过 Redis 实现跨进程、跨设备协作；同时引入基于 Go 的外部 worker（通过 Redis 通信），用于承载 CPU 密集型任务，弥补 Python 在该场景下的性能瓶颈。
+在此基础上，CelestialFlow 支持 Web 可视化监控，并提供基于 Redis 的 demo 与 Go Worker 外部协作示例，用于展示按需构建跨进程、跨设备任务协作的方式。
 
 ## 项目结构（Project Structure）
 
@@ -111,6 +111,18 @@ uv pip install celestialflow
 pip install celestialflow
 ```
 
+如果你只使用 CelestialFlow 的核心调度、Web、持久化与 demo/test 之外的常规功能，上面的安装已经足够。
+
+如果你还需要启用 CelestialTree 事件追踪能力，则需要**额外安装** `celestialtree`：
+
+```bash
+# 对已发布包使用者
+uv pip install celestialtree
+
+# 如果你是 clone 仓库后的开发者/贡献者
+uv sync --group dev
+```
+
 一个简单的可运行代码:
 
 ```python
@@ -190,7 +202,7 @@ flowchart TD
 - [runtime/util_hash.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/runtime/util_hash.md)
 - [runtime/util_types.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/runtime/util_types.md)
 - [runtime/util_errors.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/runtime/util_errors.md)
-- [persistence/core_fail.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/persistence/core_fail.md)
+- [persistence/core_fallback.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/persistence/core_fallback.md)
 - [persistence/core_log.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/src/persistence/core_log.md)
 
 如果你更喜欢通过完整案例理解框架的运行方式，可以参考这篇利用 TaskGraph 从零开始构建项目的教程：
@@ -203,20 +215,20 @@ flowchart TD
 
 你可以继续运行更多的演示代码，这里记录了各个演示文件与其中的演示函数说明：
 
-[🎮demo/](https://github.com/Mr-xiaotian/CelestialFlow/tree/main/docs/zh-CN/demo)
+[🎮demo/ 总览](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/demo/README.md)
 
-​如果你想运行测试代码, 可以先查看如下文档内容:
+如果你想运行测试代码，可以先查看如下文档内容：
 
-[🧪tests/](https://github.com/Mr-xiaotian/CelestialFlow/tree/main/docs/zh-CN/tests)
+[🧪tests/ 总览](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/tests/README.md)
 
-如果你想查看bench内容, 这里的数据成为框架中部分设计的决策依据:
+如果你想查看 bench 内容，这些数据也是框架中部分设计取舍的依据：
 
-[⚡bench/](https://github.com/Mr-xiaotian/CelestialFlow/tree/main/docs/zh-CN/bench)
+[⚡bench/ 总览](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/bench/README.md)
 
 ## 环境要求（Requirements）
 
-**CelestialFlow** 基于 Python 3.12+，并依赖以下核心组件。
-请确保你的环境能够正常安装这些依赖（`pip install celestialflow` 会自动安装）。
+**CelestialFlow** 基于 Python 3.12+，默认运行时依赖以下核心组件。
+其中 `celestialtree` 不再属于默认运行时依赖，而是额外安装的可选组件。
 
 | 依赖包           | 说明 |
 | ----------------- | ---- |
@@ -227,73 +239,74 @@ flowchart TD
 | **networkx**      | 任务图（TaskGraph）结构与依赖分析 |
 | **jinja2**        | FastAPI 模板引擎，用于 Web 可视化界面渲染 |
 | **tqdm**          | 可选组件，进度条显示，用于任务执行可视化 |
-| **redis**         | 可选组件，用于分布式任务通信（`TaskRedis*` 系列模块） |
-| **celestialtree** | 可选组件，用于任务状态上报与远程调用（`ctree_client`） |
+
+如需运行 `demo/demo_redis.py` 或 Go Worker 示例，请额外安装 `redis` 并准备 Redis 服务；这部分不属于默认运行时依赖。
+
+如需运行依赖 CelestialTree 的 demo / bench / 追踪查询，请额外安装 `celestialtree`，或直接在源码仓库中执行 `uv sync --group dev`。
 
 ## 文件结构（File Structure）
 
 <p align="center">
   <img src="https://raw.githubusercontent.com/Mr-xiaotian/CelestialFlow/main/img/file_structure.svg" alt="FileStructure" />
   <br/>
-  <em>celestial-flow 3.2.3</em>
+  <em>celestial-flow 3.2.4</em>
 </p>
 
 (该视图由我的另一个项目[CelestialVault](https://github.com/Mr-xiaotian/CelestialVault)中inst_file.FileTree.print_tree()生成。转换为图片则借助[Carbon](https://carbon.now.sh)。)
 
 ## 版本日志（Version Log）
-- 3.2.3
+- 3.2.4
   - feat:
-    - **[IMPORTANT]** 前端仪表盘设置面板中新添 `节点等待使用全局估计` 开关, 开启后节点卡片中原 `等待` 量将被替换为 `全局等待`, 并在卡片中显示 `全局剩余时间`
-      - 这个功能非常有趣, 开启前后能看到数值大幅波动
-    - **[IMPORTANT]** 重写任务注入页面, 现在实用性远远高于之前版本
-      - 可以给每个节点单独配置注入任务列表, 在一起发送
-    - **[IMPORTANT]** 移除 `TaskExecutor` 中 `get_args` 与 `process_result` 两个方法, 以及 `unpack_task_args` 属性
-      - 这是为引入泛型必要的修改
-      - `process_result` 功能很简单, 对func输出的result进行再次处理, 但事实上在输入func前对齐进行包装也能达到一样的效果
-      - `get_args` 功能更为复杂, 可以直接将前一节点提供的 `result` 转为当前节点所需的 `task` 类型, 非常灵活; 但问题在于太过灵活, 导致使用心智负担很大
-      - `unpack_task_args` 就是 `get_args` 带来的一项心智负担, 默认 `get_args` 会把 `task` 进行 `(task, )` 包裹后发送给func, 开启 `unpack_task_args` 后则直接发送
-    - **[IMPORTANT]** `graph` 的init参数中添加 `name`, 以与 `executor` `stage` 一致
-      - 破坏接口破坏性更新
-      - 在日志的 `start_graph` `end_graph` 与web端的 `graph_anaylysis` 中都有显示
-    - 彻底移除前后端通信中的 `graph_summary` , 原本残余的 `全局剩余时间` 现在拆为各个节点的 `全局等待` 与 `全局剩余时间`
-      - 这里所说的 `全局` 意为根据图论关系, 由上游剩余的任务数估算下游总共能获得多少任务
-      - 例如: 图关系 `A -> B`, A已处理任务2, 未处理任务3, B已处理任务4, 未处理任务2. 这意味着A成功的2个任务为B带来总共了6个任务, 那么我们可以据此估计B总功能获取"3/2*6=9"个任务, 因此B的 `等待` 任务数量为2, 但 `全局等待` 任务数量为5
-    - 前端中添加部分提示气泡, 鼠标放上去后可以介绍相关信息, 例如本次新加入的节点 `全局等待` 的含义
-    - 移除前端中节点卡片的拖拽功能
-      - 这个功能是在最早加入web页面时添加的, 当时感觉很帅, 但现在有点玩腻了
-    - 前端错误日志页面添加 `任务注入` 按钮, 可以把选定任务直接添加到任务注入页面中节点的代注入任务列表中
-    - 在 `TaskSplitter` 中添加 `split_item` 方法, 可自由定义
-      - 原本的 `splitter` 非常依赖于 `get_args`, 现在通过 `split_item` 方法稍微弥补其缺失的灵活性
+    - **[IMPORTANT]** 合并原有的 `fail_funnel` 与 `success_funnel` 机制为 `fallback` , 并采用 `sqlite` 进行存储
+      - 原有基于 `jsonl` 存储的fail持久化机制在存储时非常好用, 但读取时每次都需要全量读取到内存中再进行检索, 非常麻烦; 我虽然也想过用类似 `redis` 的数据库服务, 但实在不想另外启动第三方服务. 然后我意外发现 `sqlite` 完美符合我的一切要求
+      - Richard 万岁!
+      - 至于原有的 `success_funnel` 机制完全是个半成品: 只能用于 `executor`, 而不能用于 `stage`; 完全在内存存储. 所以借着这次机会也一并重构, 合并入 `fallback_funnel`
+      - 现在 `fallback_funnel` 会在任务 `注入/重复/重试/失败/成功` 时对sqlite中相应记录进行插入/更新/删除操作
+      - 其中在任务成功时默认会删除该条记录, 但如果开启 `executor` 中的 `perist_result` 选项, 则会保留该条记录, 并将 `status` 字段更新为 `success`
+    - **[IMPORTANT]** 移除 `stages` 中的三个redis节点, 并添加demo文件, 说明如果自行构建相关节点
+      - 相比 `TaskSplitter` 与 `TaskRouter`, 这三个节点实在可有可无, 还会导致多一个 `redis` 依赖包
+    - **[IMPORTANT]** `celestialtree` 不再继续作为依赖库, 现有的事件声明机制基于一套protol接口, 并默认使用本地的超简化实现
+      - 这样做同样是为了避免太多库依赖, `celestialtree` 库包含对 `grpcio` 与 `protobuf` 的依赖, 而这两者对于python free-threading版本的支持性不太好, 因此在有他们的情况下 `celestialflow` 无法在free-threading版本下运行----而这是我非常期待的
+      - 根据 `bench_gil_vs_nogil`, 在free-threading版本下, `executor` 在cpu密集任务中会得到5.25倍提升, 而 `graph` 在cpu密集任务中则会得到7.55倍提升. 非常喜人
+    - 在前端 `节点指标走向` 卡片中添加 `全局等待队列`
+    - 在 `graph` 中添加 `start_graph_db` 方法, 接受一个fallback数据库地址, 然后根据其中失败数据进行 `start_graph`; 在 `executor` 中添加 `start_db` 方法, 接受一个fallback数据库地址, 然后根据其中失败数据进行 `start`
+      - 很方便
   - refactor:
-    - **[IMPORTANT]** 引入泛型, 同时强制性要求py版本>=3.12
-      - 泛型的引入使得代码更加类型安全, 同时也提高了代码的可读性
-      - 3.12版本对泛型的表述非常直观
-    - 移除前端代码中所有对 `localStorage` 的使用
-      - 在已经有config配置文件的情况下意义不大, 反而会带来困扰
-    - 将任务队列的drain操作从graph层移至stage层
-      - 之前不能这样做是因为节点的 `stage_mode` 可能为 `process`, 此时在主进程持有的节点非真实运行的节点
-      - 算是3.2.0版本带来的持久影响之一
-    - 优化 `TaskMetric` 中对锁的使用
-    - 移除 `TaskEnvelope` 中的 `change_id()` 方法, 现在默认envelope不可变, 同时 `emit_retry_envelope` 中不再把原有的envelope的id修改后继续提交给worker, 而是直接使用新生成的envelope
-    - 移除错误日志中的 `error` `error_repr` `task_repr` 字段
-    - 修改前后端通信中任务注入数据的格式, 以方便同时提交多个节点的任务数据
-    - 前端代码中开启strict检查
-    - 将前端中 `injection.css` 文件拆分成多个文件
-    - 修改 `config.json` 的数据格式, 现在按照生效区域进行分类
-    - 收紧前端中的数据类型
-    - 添加 `ReportTaskGraph` 类型, 专门用于给reporter做类型声明
+    - **[IMPORTANT]** 将server端存储error数据的方式从py原生列表改为一个临时sqlite数据库
+      - 在锤子效应下我想更多的尝试sqlite的使用
+    - 为每个 `graph` 添加基于 `name` 与 `time.time()` 的 `graph_id` 作为唯一性标识符
+    - 重写reporter与server端的交互逻辑
+      - 现在每一轮refresh开始时都会进行状态对齐, 通过 `graph_id` 确定两者所持有的数据是否来自一个 `graph` 对象, 是的话则不用重复push structure/analysis数据
+      - 在状态对齐时如果双方的graph一致, server会返回自己所持有的错误数据中最大的 `event_id` 值, 经过严格校验, `event_id` 在数据库中严格递增
+      - 将reporter中原有的 `push_error_meta` 与 `push_error_content` 合并, 每次刷新时只发送新增的错误数据, 而新增数据则根据server返回的最大 `event_id` 值与本地数据库中的最大 `event_id` 值进行筛选
+    - 为 `graph.connect` 与 `graph_set_stage` 绑定更多职责
+      - 现在节点与 `graph` 在 `ctree` `reporter` 上的同步在 `graph_set_stage` 中完成
+      - 而 `task_queue` 与 `result_queue` 的上下流绑定, 以及 `counter` 的绑定都在 `graph.connect` 中完成
+    - 删除 `TaskEnvelope` 中无关数据, 只保留 `task` `hash` `id` 三项
+      - `source` 字段本就不该添加, 它一致没有发挥作用
+      - `prev` 字段是为了原版 `success_funnel` 而服务的, 现在已经没有必要
+    - `TaskMetrics` 中固定使用 `Lock` 对所有 `counter` 进行限定, 而无关乎 `executor` 的 `execution_mode`
+      - 这种固定的模式在牺牲部分性能的情况下使得代码更加稳定
+      - 根据 `bench_lock_overhead`, 这会导致 `counter` 慢3.2倍左右, 考虑到 `counter` 的更新全部基于 `int` 类型, 本就很快, 可以接受
+    - 在 `process_task_success` 中除去已有的一次 `task.success` 声明, 会在 `result_envelope` 进入 `result_queue` 前再进行 `task.input` 声明
+      - 为了保证fallback的sqlite中 `event_id` 全局统一
+    - `executor.get_fail_pairs`(原 `executor.get_error_pairs`) 会返回 `tuple[T, PeristedError]`
+      - `PeristedError` 由记录的 `error_type` 与 `error_message` 组成
+    - 重写 `TaskRouter` 节点, 现在必须传入一个 `router` 函数, 去指定任务的路由方向
+    - 移除一些没用的方法
+      - 比如 `TaskGraph.get_stage_input_trace`
   - fix:
-    - i18n本地化在部分字段上失效的问题
-    - 直接点击仪表盘中错误数字跳转到错误日志页后, 设置面板显示的还是仪表盘页面的设置
-    - 前端中为各项仪表盘请求添加 `RequestSeq`, 以避免前后发送两个请求, 但因为延迟关系, 先发送的请求的返回覆盖掉后发送请求的返回
-    - 修复前端中各项空字段需要在第一次refresh才显示的问题, 体感上会导致"加载"很慢
+    - 前端仪表盘页面中的结构图不会再因切换tab而显示空白
+      - 这是很古老的bug, 我不知道我为什么译制片没有修复
   - chore:
-    - 将文档更新翻译为英/日两语
-      - 这项操作太耗token了
+    - 添加更多demo
+    - 添加更多benchmark
+    - 添加 `Agents.md` 文件
+      - 我受够了无休止的对ai进行强调
 
 更多过往日志可看:
 
-[change_log.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/change_log.md )
+[change_log.md](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/docs/zh-CN/change_log.md)
 
 ## Star 历史趋势（Star History）
 
@@ -302,7 +315,7 @@ flowchart TD
 ![Star History Chart](https://api.star-history.com/svg?repos=Mr-xiaotian/CelestialFlow&type=Date)
 
 ## 许可（License）
-This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
+This project is licensed under the MIT License - see the [LICENSE](https://github.com/Mr-xiaotian/CelestialFlow/blob/main/LICENSE) file for details.
 
 ## 作者（Author）
 Author: Mr-xiaotian

{celestialflow-3.2.3 → celestialflow-3.2.4}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "celestialflow"
-version = "3.2.3"
+version = "3.2.4"
 description = "A flexible GRAPH-based task orchestration framework."
 readme = "README.md"
 license = { text = "MIT" }
@@ -18,9 +18,7 @@ dependencies = [
     "uvicorn",
     "requests",
     "networkx",
-    "redis",
     "jinja2",
-    "celestialtree>=0.1.3",
 ]
 
 classifiers = [
@@ -72,6 +70,8 @@ dev = [
     "python-dotenv>=1.2.2",
     "ruff>=0.15.0",
     "pyright>=1.1.409",
+    "redis",
+    "celestialtree>=0.1.3",
 ]
 
 [tool.pyright]

{celestialflow-3.2.3 → celestialflow-3.2.4}/src/celestialflow/__init__.py

@@ -13,19 +13,15 @@ from .graph import (
     TaskLoop,
     TaskWheel,
 )
-from .observability import BaseObserver, CallbackObserver, TaskProgress
-from .persistence.util_jsonl import (
-    load_jsonl_logs,
-    load_task_by_error,
-    load_task_by_stage,
+from .observability import BaseObserver, TaskProgress
+from .persistence.util_sqlite import (
+    load_records,
+    load_records_grouped_by_stage,
 )
 from .runtime.util_hash import make_hashable
 from .runtime.util_types import TerminationSignal
 from .stage import (
     TaskExecutor,
-    TaskRedisAck,
-    TaskRedisSource,
-    TaskRedisTransport,
     TaskRouter,
     TaskSplitter,
     TaskStage,
@@ -36,7 +32,6 @@ from .web import TaskWebServer
 
 __all__ = [
     "BaseObserver",
-    "CallbackObserver",
     "TaskChain",
     "TaskComplete",
     "TaskCross",
@@ -45,9 +40,6 @@ __all__ = [
     "TaskGrid",
     "TaskLoop",
     "TaskProgress",
-    "TaskRedisAck",
-    "TaskRedisSource",
-    "TaskRedisTransport",
     "TaskRouter",
     "TaskSplitter",
     "TaskStage",
@@ -57,8 +49,7 @@ __all__ = [
     "benchmark_executor",
     "benchmark_graph",
     "format_table",
-    "load_jsonl_logs",
-    "load_task_by_error",
-    "load_task_by_stage",
+    "load_records",
+    "load_records_grouped_by_stage",
     "make_hashable",
 ]