可观测性运维后端【免费下载链接】PulseReal-time monitoring dashboard for Proxmox VE, PBS, Docker, Kubernetes, TrueNAS and vSphere. Self-hosted, with smart alerts and AI patrols that catch silent failures.项目地址https://gitcode.com/gh_mirrors/pulse27/Pulse点击查看免费下载本文围绕 Pulse 仓库tests/qualification/navigation-reconnect/2026-09-05-integrated/README.md记录的集成资格运行展开说明导航在冷流cold stream断线WebSocket 1013 关闭后如何在不刷新页面的前提下恢复完整覆盖 8 用例验证矩阵、可复现的运行命令、前端源码级恢复机制以及验证边界与证据审计结论。读完本文你将掌握如何在本地复现 Pulse 的导航重连资格用例理解platformAdmission、resourceSnapshotReceived等恢复原语的真实作用并知道哪些结论该信、哪些不该信。背景导航在 WebSocket 冷流重连中丢失#1899Pulse 是多平台Proxmox VE、PBS、Docker、Kubernetes、TrueNAS、vSphere的实时监控面板前端导航栏中每个平台目的地destination是否出现取决于后端对当前资源库存estate的“准入admission”结论。资格认证目录的根文档 README 记录了两条重要复现路径基线复现v6.4.1 源码构建db7e26deac2a77dd5eff1dfb5bf2f1546683d5d6与集成主分支193ead50fd9559b92ee242f34b8e9718fd7a3e3e在真实连接的浏览器 WebSocket 于启动期间被以1013码关闭后六个平台目的地全部消失HTTP 健康检查仍可用、Docker 库存仍可见、System 控件仍在但仅靠 socket 恢复无法还原目的地。扩展复现集成主分支deac5e7750a79052170ba4396b700a3d6b855e3f真实 socket 重连后仅对/api/resources?page1limit1注入 HTTP 503 响应就足以让 1440/1100px 下的平台目的地消失——即使库存已填充也不能建立“规范资源快照已收到”的结论。两者都指向同一条路径告警 REST 恢复可以在首个资源帧到达之前填充activeAlerts旧实现把这一状态当作权威资源状态从而用“空 estate”覆盖了准入结果。修复方向因此锁定为独立跟踪资源快照的到达在传输重连期间保留该知识、在组织 URL 变化时清空、显式空资源快照仍视为权威而非重新设计导航。本次集成运行的结论2026-09-05 的集成运行源码c8931787adb7bc3152f060a829ebe2a1aa2a2b9c是在未对应用或测试做任何改动的前提下把此前分散修复合并验证的一次运行。其核心结果如下全部 8 个96-navigation-socket-recovery.spec.tsChromium 用例通过耗时 132 秒始于 20:43:55 UTC后端使用本地构建产物内置生产前端资源与合成库存synthetic inventory运行结束后由 runner 主动停止本地可执行文件 SHA-256 为a5aaf32fdba70744d1dfa4e0749f080dd8960dcd19d381ab6ec2fdc286d36b27——它标识的是本次源码构建的测试可执行文件而非已发布制品仓库根目录、frontend-modern与tests/integration均安装了锁定依赖runner 使用 Playwright 1.56.1 与 Chromium 项目。运行记录junit.xml保留的是未修改的 runner 结果tests8 failures0 skipped0 errors08 个用例名称均为 “populated navigation survives socket loss at {1440|1100|390|320}px (admission failure: {false|true})”。8 用例验证矩阵宽度 × 准入失败注入测试规格 96-navigation-socket-recovery.spec.ts 用两层循环构成矩阵for (const admissionFailure of [false, true]) { for (const width of [1440, 1100, 390, 320]) {即四个宽度 × 两种准入状态共 8 个用例。每个用例的执行要点如下维度说明视口1440、1100 使用高度 900390、320 使用高度 844准入失败注入仅当failAdmission为真且请求命中/api/resources?page1limit1时route 返回 503{error:qualification admission unavailable}并累计failedAdmissions断线方式通过 PlaywrightrouteWebSocket(**/ws*)捕获 socket随后以code: 1013关闭先记录performance.timeOrigin作为文档身份恢复后要求其不变健康状态断言断线后出现Backend is healthy. Live updates are reconnecting.状态/api/health仍为 200恢复后回到Backend and live data stream are connected.导航保持断线前、中、后三次采集[aria-labelPrimary navigation]的快照并做软断言expect.soft相等计数被排除告警数可独立变化桌面 incident 控制宽度 ≥ 1280 时重连期间点开 Alerts断言Acknowledge按钮可用仅证明访问/控制可用性不证明持久化或投递窄屏交互宽度 ≤ 390 时打开/关闭 More 导航、进入 Settings、在 Proxmox 与 Docker 间切换平台、打开 active incidents文档身份全程断言performance.timeOrigin不变证明恢复过程不依赖页面重载窄屏的 Docker 表格键盘访问与文本裁剪断言是条件性的仅在PULSE_E2E_TABLE_ACCESS1时执行见下文 390px 用例的if分支。测试中通过 TreeWalker 逐文本节点计算getClientRects检查裁剪字形并验证overflow-x: clip、水平滚轮与 ArrowRight 键盘行为、aria-expanded展开等。复现命令与运行前提从仓库根目录、安装锁定依赖后复现命令如下README 原样保留pulse-heavy-run -- env \ PULSE_E2E_USE_LOCAL_BACKEND1 PULSE_E2E_SKIP_PLAYWRIGHT_INSTALL1 \ PULSE_MOCK_MODEtrue PULSE_E2E_NAVIGATION_RECOVERY1 \ PULSE_E2E_TABLE_ACCESS1 \ PULSE_E2E_LOCAL_BACKEND_PORT18765 \ npm --prefix tests/integration test -- \ tests/96-navigation-socket-recovery.spec.ts --projectchromium各环境变量含义如下环境变量作用PULSE_E2E_USE_LOCAL_BACKEND1启用本地后端spec 中的enabled门控要求它与PULSE_E2E_NAVIGATION_RECOVERY1同时成立PULSE_E2E_SKIP_PLAYWRIGHT_INSTALL1跳过 Playwright 安装步骤需先手动安装固定的 ChromiumPULSE_MOCK_MODEtrue后端使用合成库存synthetic inventoryPULSE_E2E_NAVIGATION_RECOVERY1开启导航恢复资格用例opt-in默认不参与自动门禁PULSE_E2E_TABLE_ACCESS1开启窄屏 Docker 表格键盘/裁剪断言PULSE_E2E_LOCAL_BACKEND_PORT18765本地后端监听端口opt-in runner 会自行构建、启动并停止一个隔离的后端不会使用共享应用截图与浏览器/视口元数据作为附件写入 Playwright 报告。文档明确强调该 spec 不会因为“存在”就自动成为发布门禁。关于PULSE_E2E_TABLE_ACCESS的证据边界README 的“Receipt audit”一节专门说明junit.xml记录了 8 个成功用例但不记录该 flag 是否生效因此 JUnit 无法独立证明那些条件性断言确实执行过而准入失败用例只有在观察到一次失败的请求时才算有效。同时README 坦承小号更新单元格update cells在 320px 下仍会大量换行早前报告的“无文本裁剪”结果并未被本次保留的 JUnit 独立证实——文档特意说明“不暗示任何可读性重新设计”。源码级解析恢复机制是如何工作的1. WebSocket store 的resourceSnapshotReceived原语在 websocket.ts 中store 显式维护了一个独立信号// Display admission survives transport reconnects, but not an organisation // change. Alerts/status alone cannot establish an empty resource estate. const [resourceSnapshotReceived, setResourceSnapshotReceived] createSignal(false);这条注释与 README 中的修复原则逐字对应显示层准入可跨传输重连存活但不可跨组织切换存活仅有告警/状态不足以证明资源 estate 为空。单元测试 websocket-unified.test.ts 用mockWsInstance?.onclose?.({ code: 1013, reason: interruption } as CloseEvent)触发与资格用例相同的 1013 关闭断言快照状态在重连后保留为true、组织变化后回落为false。2.runtimeStateResolved不再把告警恢复误判为资源状态在 useAppRuntimeState.ts 中运行态是否“已解析”由快照原语决定而不是由activeAlerts是否被填充决定const runtimeStateResolved (): boolean { const store wsStore(); // Alert REST recovery can populate state before the first resource frame. // It must not replace valid admission with an invented empty estate. return Boolean(store?.resourceSnapshotReceived()) || (store?.state.resources.length ?? 0) 0; };这正是 README 描述的“旧实现缺陷”的修复落点告警 REST 恢复可能先于首个资源帧到达但它不再被当作权威资源状态。架构测试 App.architecture.test.ts 中的断言does not let retained reconnect admission override an explicit empty resource snapshot以及对resourceSnapshotReceived()出现在运行时谓词中的检查把这一边界固化为回归保护。3.loadPlatformAdmission请求级次supersession保护平台准入通过/api/resources?page1limit1获取一页一条已足够因为聚合描述的是全集。useAppRuntimeState.ts 用单调递增的platformAdmissionRequest编号实现“仅最新请求生效”const request platformAdmissionRequest; ... // A tenant switch or newer refresh supersedes this response, even if // that newer request failed. Never restore an outgoing tenant facet. if (request ! platformAdmissionRequest) return;失败分支刻意保持“保留最近一次有效准入结果”而不是清空或重试// A failed refresh says nothing about which platforms still exist. // Keep the last valid facet until a successful response replaces it. // First-load failures remain unresolved; org switches clear it before // requesting the new tenant, so this cannot retain outgoing admission.4. 重连事件的联动刷新socket 恢复后useAppRuntimeState.ts 通过事件总线订阅websocket_reconnected联动刷新告警配置、active alerts并重新加载平台准入const handleWebSocketReconnected () { logger.info(WebSocket reconnected, refreshing alert configuration); void alertsActivation.refreshConfig(); void alertsActivation.refreshActiveAlerts(); // The estate can gain or lose a platform while the socket is down. void loadPlatformAdmission(); };连接状态的四态模型connected/sync-reconnecting/backend-healthy/reconnecting/disconnected见 useAppRuntimeState.ts也在运行时保证后端健康但流未连接时显示Sync reconnectingBackend is healthy. Live updates are reconnecting.与测试断言的状态文案一一对应。变更数据恢复不只验证“导航不变”父级 README 与 changed-data 资格记录 明确指出本次集成运行只证明“导航保留 socket 重连 文档身份不变”不证明变更数据在断线前后同步。为此spec 尾部追加了两个“changed backend incidents recover without reload”用例1440/320px高度 900最终全矩阵10 个用例通过、无重试耗时约 2.4 分钟用例先选定一个docker-service-health类型的真实 incident按规范 ID 选择而非依赖某个固定名称或冷离线主机必要时先走unacknowledge接口复位记录performance.timeOrigin后关闭 socket在断线期间通过独立认证 API 客户端把该 incident 置为 acknowledged并断言后端值已变化而页面渲染值仍是旧值恢复连接后浏览器必须收到成功的/api/alerts/active响应、渲染同一 incident 为已确认、文档时间原点不变acknowledged 的 incident 会排在列表末尾故断言前先滚动到窗口化列表末尾第二次断线时暂停全局检测并批量清空后端 incident恢复后前后端都必须返回[]旧卡片必须从 DOM 消失最后在finally中恢复原始告警配置。该文档还保留了四条开发期失败记录initial/、standalone/、cold-fixture/、named-service/分别指向“分组假设不完整”“acknowledged 排序与列表窗口化”“冷运行下离线主机 incident 未出现”“不同生成的 estate 服务名不同”等真实调试过程并说明junit.xml.gz是对失败运行 JUnit 的字节级归档含receipt-normalisation.json中的 SHA-256 对照。组织切换下的准入竞态superseded admission父级 README 还记录了与 #1899 相邻但独立的请求排序缺陷允许“过期的外出组织准入响应”在切换组织后恢复平台目的地。修复原则是“仅允许最新的准入请求更新导航”并用脚本 check-navigation-admission-race.mjs 做纯前端的有界实验pulse-heavy-run -- bash -c for width in 390 1440; do for mode in failure success reverse; do PULSE_PROOF_WIDTH$width PULSE_PROOF_MODE$mode \ node scripts/check-navigation-admission-race.mjs || exit done done 该脚本启动本地 Vite、使用全新 Chromium 上下文、对两个组织合成 HTTP 响应与冷 socket通过eventBus.emit(websocket_reconnected)调用生产重连订阅者与真实组织选择器scripts/check-navigation-admission-race.mjs而不是替换应用 store。它断言更新的准入失败会覆盖更旧的 503 成功返回、更新的全 false 成功响应仍是权威、外出响应先于挂起的更新成功完成时也不能恢复平台导航窄屏用例还覆盖 More 菜单、Settings 跳转与恢复后切换到 Docker。每用例的截图、请求序列与精确运行时 SHA-256 收据写入tmp/navigation-admission-race/repaired-width-mode/。截图证据与呈现注意本次运行保留的两张代表性截图可直接查阅README 对此给出了两条重要解读其一两张截图仅代表“桌面重连期间的 incident 访问”与“320px 库存”其中窄屏截图单独不足以证明连接状态——连接状态由测试断言独立验证其二320px 下小号更新单元格仍明显换行与早前报告的“无裁剪文本”结果存在张力而该条件性结果无法由保留的 JUnit 独立证实。证据边界本次运行证明了什么、没证明什么README 用“Decision and limits”一节把结论严格限定在证据之内这些边界值得在引用时保留已验证8 个导航恢复用例四种宽度 × 有无准入失败注入通过额外 focused 检查中websocket-resilience与websocket-unified共 53 个测试通过internal/alerts下TestAlertCharacterizationGetActiveAlertsExportsCanonicalIdentity以-count1通过但没有运行全仓库测试套件。未验证acknowledgement 持久化、off-host 投递、重启历史、畸形告警快照、reporter 安装、发布候选分支、反向代理行为、长中断浸泡soak。已知残余REST 恢复代码仍会跳过没有可用 ID 的条目服务端正常读模型导出的类型化告警与规范身份虽有集中测试覆盖但这不是“每条畸形响应路径都不可能”的证明。曾被撤回的修复不得计入已交付若重新推进需要浏览器故障注入、真实空响应清空以及同内容性能/契约资格化。发布判断本次运行不对发布就绪性或补丁分支可回退性做任何判断“下一步更有价值的证据”是精确候选版本的恢复与已安装告警接收而非又一次输入不变的源码级导航运行。小结本次集成资格运行的价值在于它把“导航在 1013 冷流断线下消失”的缺陷修复从分散的单元/架构测试提升为真实 Chromium 隔离本地后端 生产前端资源的端到端验证并明确划出了证据边界。前端侧的三条机制——resourceSnapshotReceived独立跟踪资源快照、platformAdmissionRequest请求级次保证最新准入生效、websocket_reconnected事件联动刷新——共同构成了无刷新恢复的底层保障。对 Pulse 的使用者而言本文给出的复现命令与源码路径可直接用于自行验证对维护者而言文档对“JUnit 不能证明 opt-in flag 生效”“窄屏截图不证明连接状态”这类细节的诚实记录本身就是可复用的资格化方法论。赞分享可观测性运维后端【免费下载链接】PulseReal-time monitoring dashboard for Proxmox VE, PBS, Docker, Kubernetes, TrueNAS and vSphere. Self-hosted, with smart alerts and AI patrols that catch silent failures.项目地址https://gitcode.com/gh_mirrors/pulse27/Pulse点击查看免费下载相关推荐Pixelle-Video 快速上手指南从一句主题到成片只需 3 步Pixelle Video 快速上手指南从一句主题到成片只需 3 步 Pixelle Video 是一个 AI 全自动短视频引擎。你只需输入一个主题它会自动人工智能AI 应用音视频媒体生成NaLLM数据处理全流程从非结构化文本到知识图谱的转换魔法NaLLM数据处理全流程从非结构化文本到知识图谱的转换魔法 NaLLM是一个强大的开源项目它能够将非结构化文本数据转换为结构化的知识图谱帮助用户更好地组织Notesnook Sync Server开源自托管笔记同步服务器的终极指南Notesnook Sync Server开源自托管笔记同步服务器的终极指南 在当今数字时代数据隐私和控制权变得前所未有的重要。 Notesnook Syn创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?