DBA误操作module表，导致3个月内包记录的dist_shasum不匹配，请教如何无痛解决

[gengengengengen]

抱歉占用大佬们精力，本人所在项目还在用cnpmjs，事发突然确实没有更好渠道反映问题，望海涵。下面是具体问题描述：

1. DBA对module表进行维护时（神奇过程不赘述），不慎将3个月内module表记录的id全部变成了0。随后cnpm触发自动同步后(模式exist)，全库不论npm包还是私有包，3个月内的dist信息均因此错乱。

2. 补救时，去掉了受影响的包记录，并且对受影响的包进行了重新同步或发布，CI恢复了正常。本以为万事大吉，但CI在拿掉缓存后，还发现3个月前的包，下载时也有dist_shasum信息对不上的情况，导致npm install失败。这里就不明白为什么时间范围外的包，sha也变化了。

3. 目前想法是根据实际下载的包的sha，重新更新module表里的sha，或者全库都进行一遍重新同步或发布，但要么操作繁琐要么动静实在太大。项目是老项目，目前大家对部署的这版cnpmjs运行机制还不够了解，且各包依赖发生变化后可能有其他风险，恐怕节外生枝。

请教各位大佬，有无更好方法解决这个问题？

[github-actions[bot]]

我们已经看到你的反馈，如果是功能缺陷，可以提供一下重现该问题的方式；如果是新功能需求，我们会尽快加入讨论。同时我们非常期待你可以加入我们的贡献者行列，让项目可以长期可持续发展。

[fengmk2]

数据库历史有备份的吧？最好直接回滚数据库。

[gengengengengen]

数据库历史有备份的吧？最好直接回滚数据库。

现在已经没有备份了，补救完已过1周，今天才发现问题描述的情况。我又调查了一下module表，似乎将dist_shasum列、package列内json的shasum信息都改过就能解决。但获取CI所下载的所有依赖版本，以及进一步获取各依赖sha并修改回module表还是挺麻烦的

目前发现仅修改shasum字段信息，也不好使，实际包的sha信息应该也被用来做比较了。目前对于私有模块都进行了重发布，但对于外网npm下载的模块，只能全清理掉再重新同步吗？

[elrrrrrrr]

😂 直接升级成 cnpmcore 部署方式？

https://github.com/cnpm/cnpmcore/issues/338

[gengengengengen]

😂 直接升级成 cnpmcore 部署方式？

338

这么刺激的吗，如果升级再同步老数据，对于错乱的数据而言清理工作好像一点都不能少，凭感觉说的，还没了解 cnpmcore