dns 里那两行 hackfix 有点丑
index 得对齐否则会出问题，这么干心智负担小
反正早晚要重构

本质是提供进来的数据非法还是fast fail好一点 不然错误的数据在里面躺半天没人知道 我觉得这不能算问题

他们翻下车咱们一起完这不合理

除非把 https://github.com/XTLS/Xray-rules-dat 安排上

不行配置加个开关允许忽略错误？

不是有一个 Scheduled assets update 的CI吗 在里面检查一下 错误不更新然后抛出来就好 release没有问题就行 自己更的他们自己想办法吧

不对 都费事搓这种东西了 直接pr到他们仓库的ci check就行了

release没有问题就行 自己更的他们自己想办法吧

我也是自动更新不过是周更所以这次没事

事实上光靠 shell 根本没法测试，除非我们提供一个 testgeodata 命令
那么 shell 还得去额外做很多事情

更新失败了更是同样的没人管

不如 core 直接忽略错误来的方便

geoip 上次重构的时候我也把非法 cidr 给忽略了来着……
那个不像 site 这么容易出错

我看了 Loyalsoldier 和 v2fly
给他们的 ci 加测试有点麻烦
有点过于简陋了

干脆都算了吧 这套玩意那么运行好几年了也就这一次放送事故

geodata 里的东西没那么严谨，甚至都不太正确
没必要为了保护它而快速失败，它们没有那个价值

而且隔壁似乎不受影响
不知道是因为他们的 fork 更新频率低
还是像这样忽略非法 rule 了 已确认 sing-box 也同样受影响

受波及的好像就 *ray，这样搞得小白以为隔壁更稳定一样

之前 ai 分类改名也搞挂了许多人，隔壁 sb 也受波及

这种 case 也应该处理
但一整个分类都错仅记录日志不太好
或许启动 1 分钟后自动关闭核心是个好主意

又翻了一下 看起来这次事确实挂了好多人 哎

在 ci 里面加检查的话要加 go，光靠 shell 很难搞，因为用的两边用的正则细节上有差异要单独处理可能有其它问题
core 忽略错误数据也不是不行，不过仅限处理 geodata 内就行，用户自己写错的该 fail 还是要 fail 不然幽灵 issues 更麻烦
至于上游改名这种事估计除了在制作 data 的时候加兼容占位符以外几乎没有什么好办法，因为分不清是用户写错的还是上游干的

是的，不能放任不管
下游项目不方便校验 geodata 而且好多都是 shell 根本没能力校验

并且好多 end-user 挂了就恢复不了了，因为这东西基本都走代理更新，死循环了属于
openwrt 你不能指望小白会 ssh 自己去替换文件
然后手机压根修不了只能等死

geosite/ip 分类内的某些条目非法直接忽略一点毛病没有

分类改名怎么办？
我觉得一分钟后关闭核心其实可以考虑
引起注意的同时不至于陷入死循环，还有个更新 geodat 的机会

分类改名的话提供一个不依赖除了配置文件的其它外部文件的安全模式也不是不行，考虑到服务器可以直接更新，有的地方直连更新也有可能成功

Xray-rules-dat 要安排的话遇到有问题的条目直接报错终止不要生成文件，这样能保证出来的数据文件不会有错误问题

core 的话不好说用户到时候用的是哪里来的 geodata，有问题条目忽略并日志记录就行

上游换 geoip 的时候提过一嘴 Xray-rules-dat 这事，当时没想好有没有什么能做到特色的东西持了保守态度，不过看最近的维护状况感觉也该上了

这 rules dat 层层依赖也很难绷，如果你们想加些什么东西的话可以维护起来 Xray-rules-dat，不然直接用别人维护的更方便一些

而且人工维护的多少有疏漏、错误、更新不及时等，能不能搞个 AI 自己去维护一份 rules dat

@Meo597 现在的处理方式是报错并且阻止 core 启动吗，这样挺好的

此 pr 之前是遇到任何规则错误直接阻止启动
这导致规则库分类中比如 geosite:cn 有任何一个条目错了直接全部歇菜

这不合理，因为这个东西错一两条无所谓，他本来也不准，不应该为此付出代价

所长此 pr 改成错一两条直接忽略

然后上面讨论的是分类改名应该如何处理，未果，没啥好办法，我觉得或许可以检测到错误一分钟后关闭核心

这样用户有感知，又不至于翻不出去导致无法获取最新的正确的 geodat

普通用户不应该为个别人员的粗心买单，core应该做的是尽量跑起来，然后提示遇到的任何错误信息，而不是直接关闭，这只会劝退小白用户

这不合理，因为这个东西错一两条无所谓，他本来也不准，不应该为此付出代价

那就这样吧

所长此 pr 改成错一两条直接忽略

有报错吗

有 err 级别日志

普通用户不应该为个别人员的粗心买单

恰恰相反，个别人员的粗心会导致所有用户买单，请仔细了解来龙去脉

普通用户不应该为个别人员的粗心买单

恰恰相反，个别人员的粗心会导致所有用户买单，请仔细了解来龙去脉

？我说的话好像和你这个pr没有冲突吧，正是因为个别人的粗心导致所有人买单，所以你提出了这个pr，但是其他人似乎有不同观点，所以我附和了你这个pr

确实小白大概没能力去依照报错把引起错误的配置删掉然后把 core 跑起来并回滚 geo 文件，这大概就是这次影响有点严重的原因

话说之前的报错是不是也没精确到是哪条配置（比如 geo cn）引起的错误

确实小白大概没能力去依照报错把引起错误的配置删掉然后把 core 跑起来并回滚 geo 文件，这大概就是这次影响有点严重的原因

话说之前的报错是不是也没精确到是哪条配置（比如 geo cn）引起的错误

没有，只能看出似乎是geo dat的问题

我说的话好像和你这个pr没有冲突吧

我误以为你说的粗心是他们上面提到的，有人粗心把分类名写错

之前报错信息也不太统一，不好定位

总之目前如果 geodat 改名，还是会直接启动失败

上次 ai 分类改名的事情应该不会再发生了吧
如果有就下个 pr 见