CnosDB中ES日志接口创建表命令的异常处理问题分析

问题背景

在CnosDB 2.4.0版本中，使用ES日志接口(eslog)创建表时发现了一个异常行为。当通过HTTP API发送包含create命令的请求时，即使表已经存在且创建成功，系统也不会返回任何错误信息，而是静默处理了该请求。

问题复现

通过以下curl命令可以向CnosDB发送ES格式的日志数据：

curl -i -u "root:" -XPOST 'http://127.0.0.1:9902/api/v1/es/write?table=test001&msg_field=msg' -d '{"index":{}}
{"msg" : "123"}
{"create":{}}
{"msg" : "456"}
{"index":{}}
{"msg" : "111"}'

执行后，虽然包含了create命令，但系统返回了HTTP 200状态码，且所有数据都被成功写入test001表中：

+-------------------------------+------+
| time                          | _msg |
+-------------------------------+------+
| 2024-04-18T03:55:45.323702794 | 123  |
| 2024-04-18T03:55:45.323704468 | 456  |
| 2024-04-18T03:55:45.323704910 | 111  |
+-------------------------------+------+

技术分析

预期行为

在Elasticsearch的标准行为中，create命令用于创建新文档。如果文档已存在，应该返回错误。类似地，在CnosDB的ES日志接口中，create命令应该遵循类似的语义：

1. 当表不存在时，create命令应该创建新表
2. 当表已存在时，create命令应该返回错误或警告

实际行为

当前实现中，无论表是否存在，create命令都会被静默处理，系统不会返回任何错误或警告信息。这可能导致以下问题：

1. 用户无法确认表是否真正被创建
2. 可能掩盖了潜在的表创建失败情况
3. 与ES接口的预期行为不一致，可能造成混淆

影响范围

该问题主要影响：

1. 使用ES日志接口的用户
2. 依赖create命令返回状态进行后续处理的自动化脚本
3. 需要精确控制表创建流程的应用场景

解决方案

该问题已在相关PR中得到修复，主要改进包括：

1. 正确处理create命令的返回状态
2. 当表已存在时返回适当的错误信息
3. 添加了相应的测试用例确保行为符合预期

最佳实践建议

对于使用CnosDB ES日志接口的用户，建议：

1. 创建表前先检查表是否存在
2. 不要过度依赖create命令来隐式创建表
3. 明确区分表创建和数据写入操作
4. 升级到包含修复的版本以获得更可靠的行为

总结

CnosDB的ES日志接口提供了与Elasticsearch兼容的API，但在某些细节行为上需要保持一致性。这个create命令的问题修复提高了接口的可靠性和可预测性，使得用户能够更准确地控制表的创建过程。