WireMock 200状态Stub正常，服务故障类Stub返回404请求头不匹配

问题根因 #

1. 故障Stub响应结构配置错误：你将业务返回字段timetamp、error、message直接写在了WireMock Stub的response根节点下，WireMock仅识别官方定义的status/headers/body/bodyFileName等响应配置字段，自定义业务字段不会被识别为响应体内容。
2. 头匹配规则冲突：从运行日志可见，请求携带了encryptedName请求头，但你配置的Stub未对该头做匹配规则声明，导致匹配失败，通常是两种情况：
   • 你开启了WireMock全请求头严格匹配参数，要求请求所有头必须和Stub配置的头完全一致，多余头会触发匹配失败
   • 存在其他优先级更高的Stub配置了encryptedName的匹配规则，优先命中了不匹配的Stub

修复步骤 #

1. 修正故障Stub配置 #

把要返回的错误内容写入body字段，同时设置更高的优先级（priority字段数值越小优先级越高），避免被其他Stub拦截：

{
  "priority": 1,
  "request": {
    "method": "GET",
    "url": "/api/v1/customer",
    "headers": {
      "Content-Type": {
        "equalTo": "application/json"
      },
      "name": {
        "equalTo": "johnDoe2"
      }
    }
  },
  "response": {
    "status": 504,
    "headers": {
      "Content-Type": "application/json"
    },
    "body": "{\"timestamp\": \"2021-02-09 14:29:50\",\"message\": null,\"error\": \"java.net.SocketTimeoutException\"}"
  }
}

如果习惯用外部文件存储响应体，也可以把body替换为bodyFileName指向对应的504响应JSON文件即可。
提示：如果需要同一请求参数支持正常/故障两种返回，可以把故障Stub的name头匹配规则改成和200 Stub一致，需要模拟故障时加载该高优先级Stub，不需要时移除即可，无需修改请求参数。

2. 修复头匹配问题 #

二选一即可：

• 关闭全头严格匹配：Spring Cloud Contract WireMock对应配置为wiremock.stub.request-headers.match=ONLY_DEFINED（默认就是该值，如果你之前修改为ALL改回即可）
• 兼容encryptedName头：在Stub的headers配置中添加如下规则，允许携带该头且不校验值：

"headers": {
  // 保留原有其他头的匹配规则
  "encryptedName": {
    "absent": false
  }
}

3. 验证 #

请求时携带name: johnDoe2头即可命中504故障Stub，返回预期的错误响应。

内容的提问来源于stack exchange，提问作者Rocky4Ever