|
|
b3f4d1af64
|
feat: 客退数据监控五仓看板与本地运行稳定性加固
功能：
- 退货库存预警：横林二仓/苏北/睢宁/山东青岗集/河南洛宁 五张看板，
按各仓客退上架仓对应的自定义库存位取数（各仓位不同：横林/苏北/睢宁 c1，山东 c2）
- 支持导入聚水潭「箱及仓位库存」导出文件覆盖创建时间、件数、供应商
（副本只有仓库级数量，没有箱级维度，真实上架时间只能靠导入）
- 退货入库核销与每日库存监控：状态落本地系统库，含定时任务与差异清单
- 服务端导出（xlsx/csv），不受列表分页与展示上限约束
稳定性：
- 前端幂等请求在后端重启窗口内自动退避重连，不再直接抛 500
- 后端补齐统一 JSON 错误兜底与 /api JSON 404，异常不再返回 HTML
- 隧道 ssh 改为绝对路径解析并隐藏窗口，避免非交互式启动 ENOENT 与黑窗弹窗
- 业务库 DATETIME 按北京时间解析（useUTC: false），修复时间显示整体 +8 小时
合并：与上游「隧道断线自愈 + 配置负缓存」为同一问题的两份实现，
本分支采用上游方案（带 TTL 的负缓存 + 统一失效函数 + 单测）。
|
2026-09-23 11:32:16 +08:00 |
|
|
|
38fa3f2127
|
fix: 隧道断线自愈 + 修复配置负缓存永久固化
远端 RST 会把隧道反复踢掉（09-20 实测当天断 5 次，每次存活 15~25 分钟）。原先的
实现把「一次网络抖动」放大成「整个开发栈不可用」，根因有两处，本次一并修掉。
1) scripts/start-remote.mjs —— 隧道断了却拉着应用陪葬
隧道进程 exit 时直接 stopChildren()，把后端和前端一起杀掉，于是每一次 RST 都
升级成一次「网站打不开」，还得靠外部守护清残留、整树重启才能恢复。
改为「退避重连隧道本身，后端/前端进程不受影响」——这正是 autossh 的语义
（autossh 只负责重启 ssh，从不牵连被它服务的应用）。建立失败走 1s→30s 指数
退避，建立成功即重置退避。
顺带补齐保活参数：TCPKeepAlive=yes、ConnectTimeout=10，探活间隔 30s → 15s，
以便更快发现已被对端 RST 的死连接。
2) backend/src/config/cloudDatabase.js —— 配置负缓存被永久固化
系统库读取失败时把「空候选」写进缓存，而入口判断是
`if (cachedCloudConfigCandidates)` —— [] 在 JS 里是 truthy，于是这次失败被
永久固化：之后永不重试，直接抛「业务数据库尚未配置」500，隧道恢复了也没用，
必须重启后端。
改为「带 TTL 的负缓存」（默认 30s，可用 CLOUD_DB_CONFIG_NEGATIVE_TTL_MS 调整）：
入口用 `!== null` 判断，失败态到期自动重新解析，使隧道恢复后无需人工干预。
缓存清理收敛到 invalidateCloudConfigCache() 单点，避免日后只清数组、忘了清
TTL 时间戳而退化回「永不过期」。同时让「测试连接」入口显式失效，保证用户改完
配置点测试能立即看到真实结果。
顺带把请求超时默认值 600000ms → 60000ms：10 分钟 × maxAttempts=2 最坏挂
20 分钟，用户体感就是「卡死」；冷查实测 16~42s，60s 仍有充足余量。
验证：
- 新增 backend/test/cloudDatabaseConfigCache.test.js，锁定负缓存三段语义
（TTL 内不重复解析 / 到期必须重试 / 上游恢复后自动复原且成功态不被 TTL 淘汰）；
test/remote-access.test.mjs 补隧道保活参数、退避曲线，以及「自愈循环不得调用
stopChildren」的防腐化断言。
- 两处均做对照组实验：去掉保护后测试如实报错（负缓存 → 报 TTL 到期未重试；
隧道 → 把 stopChildren 加回去即被用例抓住），证明用例真能拦住回归。
- 后端全量 340 项 / 339 通过，唯一失败为 resilientSecretStore 的 Windows 权限
断言（环境固有，与本次无关）；check-syntax 通过。
- 本地实测：kill 掉隧道进程后 1 秒内自动重建（PID 36268 → 15816），后端进程
PID 未变（29580）、/health 仍返回 200。
|
2026-09-22 19:32:40 +08:00 |
|
|
|
445347e664
|
feat: 启用运营分析模块，新增模块化库存监控与 MKH-BOM 资料
本次将此前被列入退役名单的运营分析相关模块恢复为可用，并新增「模块化库存监控」
一级菜单及其两个子页面。
主要变更：
1. 恢复启用：商品监控、激励看板、营销活动、推广模块、商品分析
- retiredFeatures 移出对应退役名单与清表语句，改为正常保留
- 补齐后端路由、前端页面与 API 封装、侧边栏配置、桌面客户端能力项
- 同步更新 retiredFeatures / retiredRoutes / retiredNavigation / desktopSessionService 测试
2. 新增「模块化库存监控」一级菜单
- 配件库存监控：仅取「简尚-崔桥工厂半成品包装项目仓」SKU 的实时库存、
当日入库/出库、近 7 日日均发货量、库存可用天数与预警（库存可用天数 ≤ 7 预警）
- MKH-BOM资料：按商品编码展示配件明细、数量、仓位、库存，支持 A4 纵向打印
3. 新增产品资料系统数据库（PostgreSQL）连接模块：读取系统库 database_configs 中
name = product_information_database 的配置，凭据只从配置读取，不落代码
4. 新增系统设置页配置项：商品标签配置、部门商品标签配置、部门SKU负责人配置
5. 旧 /api/dashboard 接口迁移至 /api/productAnalysis，仪表盘预览页改用新接口，
相应移除 dashboard 路由模块及其测试
6. 修复 retiredRoutes 测试在 Windows 下挂起超时的问题：该测试用
parent.filename.endsWith('/api/planningUpload.js') 判断是否注入 mock，
而 Windows 的 filename 为反斜杠路径，导致判断恒为 false、mock 全部失效、
真实模块去连中央系统库而挂起（Linux CI 正常）。改为平台无关的路径匹配。
7. .gitignore 忽略本地验证产物（outputs/、.git-status.txt）
验证：
- 前端：lint / test（16 项）/ build（含 planning entry 校验）全部通过
- 后端：语法检查 149 个文件通过；测试 38/39 通过
- 已知未通过项：resilientSecretStore.test.js 断言密钥备份文件权限为 0o600，
Windows 下 chmod 无法表达该权限（实际为 0o666），属既有的平台相关失败，
与本次改动无关，本次未修改该文件
- 说明：本机 frontend/ 下存在未纳入版本库的旧依赖备份目录 node_modules_old_*，
会污染 ESLint 扫描（十余万条第三方报错），故 lint 步骤以
--ignore-pattern node_modules_old_*/** 排除后执行，其余步骤与仓库 check 一致
未提交内容：本地验证截图 outputs/ 与 .git-status.txt 已被 .gitignore 排除。
|
2026-09-15 16:53:12 +08:00 |
|
lunanting
|
3239d6a558
|
feat: bootstrap local instances from central system database
|
2026-09-12 16:06:01 +08:00 |
|
