Hello guys. I have an intermittent issue. ~3 of 20...
# help
а
Hello guys. I have an intermittent issue. ~3 of 200 runs matching response is not found. Mapping:
Copy code
{
  "priority": 3,
  "request": {
    "method": "POST",
    "urlPath": "...",
    "bodyPatterns": [
      {
        "matchesXPath": "//ns2:message[contains(text(),'ItemCode=\"MIN_PRC_TST_0002\"')]",
        "xPathNamespaces": {
          "ns2": "...",
          "SOAP-ENV": "..."
        }
      }
    ]
  },
  "response": {
    "status": 200,
    "bodyFileName": "*"
  }
}
Request body is almost the same every time (just time and number of request are changing) Error in WireMock logs:
Warning: failed to evaluate the XPath expression //ns2:message[contains(text(),'ItemCode="MIN_PRC_TST_0002"')]
Do you know how to fix? P.S. this is not a single failing case. For example xPath "//tem:ProcessMessage[node()][contains(.,'INT_TST_0007')]" sometimes fails the same way. Thank you.
t
Does this fail reliably i.e. same number of times, same position in run each time or is it random?
а
Random
t
WireMock doesn’t do a great job of reporting the full error here. I suggest setting a breakpoint on
MatchesXPathPattern:124
and doing a “run until failure”, then you should be able to see the underlying exception that’s causing this.
а
Hi Tom. I debugged as you suggest and underlying exception was "Prefix must resolve to a namespace" that means namespace using in xPath expression is not found in xPathNamespaces I set in mapping file. But it must be found as you can see from example above. During debug I found that sometimes namespace context of the xPath object is changing by another thread, because of using InheritableThreadLocal as a cache for xPath. I changed it to simple ThreadLocal and errors desappeared. I created a PR with this change, could you please consider to merge it? https://github.com/wiremock/wiremock/pull/2618 Thank you.
t
I’m happy to merge this, although I’m troubled that this should be the fix. I can’t see how the inheritance mechanism should make any difference. In your debugging, did you see which thread the namespaces were being set vs. used in?
а
Difference - one thread is running in
XmlDocument:57
(evaluating xPath expression) and another thread (e.g. child) is setting another namespace context in
XmlDocument:54
. I attached screenshots from debugging where you can see that prefixResolver somehow changing whet it's just passing into constructor without a change. Prefix resolver is an attribute of xPath object.
t
Maybe I’m misunderstanding something, but that’s the same thread in both screenshots isn’t it?
Anyway, I’m happy to accept the PR anyway. I don’t want this to block a fix, would just like to understand it as it’s messing with my mental models a bit.
а
Yes it's the same thread. I wanted to show this mystical change. Below there are screenshots from different threads where you can see that threads are using one xPath object and setting different namespace context into it.