适用版本： 7.17-8.9
1. 错误异常的基本描述 #
failed to create RescoreSearchContext 表示 Elasticsearch 在执行搜索请求时，尝试为 rescore 阶段构建搜索上下文（SearchContext）失败，抛出了 SearchException。该异常通常发生在搜索请求包含 rescore 配置，而 Elasticsearch 在为每一个 rescore 构建上下文（RescoreSearchContext）时触发了 IOException。
常见现象 #
- 搜索请求返回
500或SearchPhaseExecutionException，并在异常信息中包含failed to create RescoreSearchContext。 - 应用侧表现为搜索失败，且错误稳定复现（只要携带
rescore就会失败）。 - 在 Elasticsearch 服务端日志中可以检索到
failed to create RescoreSearchContext以及被包装的底层IOException堆栈。 - 如果请求中包含多个
rescore，只要其中一个构建失败，整个搜索请求就会失败。
典型报错与异常栈 #
实际异常栈通常类似下面这样：
SearchException[failed to create RescoreSearchContext]
Caused by: IOException
at org.elasticsearch.search.SearchService.createContext(...)
at org.elasticsearch.search.SearchService.executeQueryPhase(...)
在某些情况下，底层还会叠加字段不存在、脚本编译失败、查询类型不兼容等更具体的异常信息。
2. 为什么会发生这个错误 #
rescore 是 Elasticsearch 中用于对主查询结果的前 N 条文档进行二次打分（二次评分）的机制。它在主查询返回结果后、最终排序输出前执行，因此 rescore 上下文的构建发生在搜索执行的早期阶段。
从源码可以确定，问题出在以下代码段中：
for (RescorerBuilder<?> rescore : source.rescores()) {
context.addRescore(rescore.buildContext(searchExecutionContext));
}
即在遍历 source.rescores() 并为每个 RescorerBuilder 调用 buildContext() 时抛出了 IOException。
常见原因通常包括：
- rescore 查询引用了不存在的字段：
rescore中的查询（query或rescore_query）引用了当前索引 mapping 中不存在或类型不匹配的字段。 - 脚本编译或执行失败：rescore 中使用了脚本（
script），而脚本本身存在语法错误、引用了不存在的字段，或使用了当前版本不支持的脚本特性。 - 查询类型与版本不兼容：
rescore中使用的查询类型在当前 Elasticsearch 版本中不被支持，或参数格式不符合当前版本的要求。 - 索引 mapping 与请求不匹配：同一个搜索请求可能命中多个索引，而这些索引的 mapping 不一致，导致 rescore 查询在部分分片上构建上下文时失败。
- 资源限制或上下文构建超时：在极端情况下，rescore 查询过于复杂，导致上下文构建阶段消耗过多资源，触发底层 IO 或内存异常。
3. 如何排查这个异常 #
建议按"先简化、再定位、后修复"的顺序处理：
- 先移除
rescore验证主查询：将搜索请求中的rescore部分临时删除，确认主查询本身是否能正常执行。如果主查询也失败，则应先修复主查询问题。 - 逐个还原
rescore：如果请求中包含多个rescore，逐个添加回来，定位具体是哪个rescore配置触发了异常。 - 检查
rescore配置：重点确认window_size是否合理、query中的查询类型是否合法、引用的字段是否存在于索引 mapping 中。 - 查看服务端完整异常栈：
failed to create RescoreSearchContext是包装后的异常，真正的根因通常在Caused by部分，需要结合完整日志判断。 - 确认索引 mapping 一致性：如果搜索请求命中多个索引，使用
GET /<index>/_mapping对比各索引的字段定义，确认 rescore 中引用的字段在所有目标索引中都存在且类型一致。
排查时需要注意的问题 #
- 不要只看
failed to create RescoreSearchContext这个表层异常，必须查看Caused by中的底层异常，才能定位真正的根因。 rescore只对主查询返回的前 N 条结果生效，但上下文构建阶段会在所有相关分片上执行，因此即使主查询返回结果为空，rescore 上下文构建仍然可能失败。- 如果是在生产环境出现问题，优先在测试环境用相同的 mapping 和请求复现，避免直接在生产环境反复尝试。
4. 如何解决这个错误 #
常用修复思路 #
- 修正 rescore 中的字段引用：确认
rescore.query中引用的所有字段都存在于目标索引的 mapping 中，且字段类型与查询方式匹配。 - 简化 rescore 查询逻辑：如果 rescore 查询过于复杂（如嵌套多层 bool 查询、使用复杂脚本），先简化为最基础的
match或term查询，确认上下文能正常构建后再逐步恢复复杂度。 - 调整 window_size：
window_size决定了参与重评分的文档数量，过小或过大都可能引发问题。建议从较小值（如 10-100）开始测试。 - 检查脚本合法性：如果 rescore 中使用了
script，确认脚本可以通过_scriptsAPI 正常编译，并且引用的字段和参数都正确。 - 统一多索引 mapping：如果搜索请求需要覆盖多个索引，确保这些索引的 mapping 对 rescore 中使用的字段定义一致，必要时可以通过索引模板统一 mapping。
修复示例 #
以下是一个典型的 rescore 配置修正示例：
{
"query": {
"match": {
"content": "elasticsearch"
}
},
"rescore": {
"window_size": 50,
"query": {
"rescore_query": {
"match": {
"title": {
"query": "elasticsearch",
"boost": 2.0
}
}
}
}
}
}
如果 title 字段不存在，修正方式为确认字段名是否正确，或使用存在的字段替换。
后续注意事项与推荐建议 #
- 对使用
rescore的搜索请求建立单独的测试case，在索引 mapping 变更时主动回归，避免 mapping 变更后 rescore 无声失败。 - 为
rescore中的查询设置合理的window_size，避免对大量文档进行重评分导致资源浪费。 - 在开发阶段使用
_validate/api验证查询 DSL 的合法性，尽早发现字段引用或查询类型的问题。
借助 INFINI 产品提升排障效率 #
- INFINI Console 适合查看集群健康度、索引 mapping、搜索请求的执行情况和错误趋势，帮助快速判断 rescore 失败是字段问题、查询问题还是集群问题。
- INFINI Gateway 适合部署在 Elasticsearch 前面做请求观测、DSL 校验和流量治理，可以在请求到达 Elasticsearch 之前拦截不合法的 rescore 配置，保护集群稳定性。
- 建议把搜索请求的 DSL、报错信息和索引 mapping 统一接入监控面板，缩短从"搜索失败"到"定位 rescore 配置问题"的时间。
5. 小结 #
failed to create RescoreSearchContext 的本质是 rescore 上下文构建失败，而不是最终排序结果错误。排查时应直接聚焦于 rescore 配置本身——包括其引用的字段、查询类型、脚本和参数是否合理，以及是否与目标索引的 mapping 兼容。
只要按照"先确认主查询正常 → 再逐个验证 rescore 配置 → 最后结合 mapping 和日志定位根因"的顺序处理，大多数情况下都可以快速定位并修复问题。对于生产环境中频繁使用 rescore 的场景，建议结合 INFINI Console 和 INFINI Gateway 实现持续的请求观测与防护。
相关错误 #
附：日志上下文 #
下面保留当前页面中的源码片段，便于继续结合异常调用栈定位问题：
try {
for (RescorerBuilder<?> rescore : source.rescores()) {
context.addRescore(rescore.buildContext(searchExecutionContext));
}
} catch (IOException e) {
throw new SearchException(shardTarget, "failed to create RescoreSearchContext", e);
}
if (source.explain() != null) {
context.explain(source.explain());
}
