BadNoMatch
BadBrowse paths
BadNoMatch means the request was well formed but nothing satisfied it: a browse path element matched no target, or a query filter matched no node. Diagnose it exactly like BadNotFound - check the QualifiedName namespace, the reference type of the path element, and whether the member is optional on this instance.
What you actually see
A browse path that resolves against one machine returns no match against an apparently identical one, or a query that worked in a test system returns nothing in production.
Why it happens
- QualifiedName namespace mismatchThe target name in a RelativePathElement is a QualifiedName. Companion specification names belong to that specification's namespace. Supplying namespace 0 with the right text matches nothing, which is the most common cause of both this code and BadNotFound.
- The step goes the wrong wayRelativePathElement carries an IsInverse flag. Walking down to a component is a forward step; reaching a parent or an owning object is an inverse one. A path with the wrong direction is valid and matches nothing.
- The target is behind a non-hierarchical referenceHasTypeDefinition, HasEncoding and similar are non-hierarchical. A path element restricted to HierarchicalReferences, which is the sensible default for walking a model, will never reach them.
- The optional member is not instantiatedTwo machines of the same type can differ in which optional members they implement. The path is correct against the type definition and matches nothing on this instance, which is why the same client works on one line and not on another.
- A filter that excludes everythingWhere a server implements query or filtered lookups, an over-specific filter returns no match rather than an error. Relax one criterion at a time to find which one is doing the excluding.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Browse the parent and list the actual childrenRead BrowseName - with its namespace index - and NodeClass for every child of the node where the path stops. Comparing that list against what you asked for ends the investigation immediately in most cases.
- Rebuild the QualifiedNames from NamespaceArrayResolve each companion specification URI to its current index at connect and construct the path names with those indices. Do not hardcode either the index or a bare string.
- Check direction and reference type per elementSet ReferenceTypeId, IncludeSubtypes and IsInverse deliberately on each RelativePathElement rather than relying on defaults that vary between SDK helpers.
- Confirm the modelling rule on the typeBrowse the type definition through HasTypeDefinition and check whether the member is Mandatory or Optional. Optional absences need a graceful fallback in the client, not a fix on the server.
- Fall back to a bounded browseWhere a path is genuinely unpredictable across machines, browse one level with a NodeClassMask and match on BrowseName in the client. It is slower than a path translation but resilient to optional members.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| opcua-commander | Its Reference Explorer toggles between forward, backward and all references, which makes it easy to see whether the target you want is reachable in the direction your path assumes. |
| asyncua (Python) | get_child with a list of prefixed names raises when nothing matches. Catch it and fall back to browsing children and matching in code when the member is optional across a fleet. |
| node-opcua | The result array carries a per-path StatusCode with the index of the element that failed, which tells you exactly where in the path to look. |
| UaExpert | Browsing the parent node and reading BrowseName on each child is the manual version of the fix, and it is often faster than reasoning about the path in code. |
| umati Sample Server | Its machines are modelled to published companion specifications, so a path that fails there and succeeds in your test rig usually means your test rig is not modelling the specification faithfully. |
| Eclipse Milo | The public demo server at opc.tcp://milo.digitalpetri.com:62541/milo is convenient for verifying that your path translation code behaves correctly against a known address space before pointing it at a machine. |
What it looks like in the log
TranslateBrowsePathsToNodeIds returned BadNoMatch for path /2:Identification/2:SerialNumber
No target matched QualifiedName 0:OperationMode from ns=4;i=5002
Relative path element 1 is inverse; no parent reference of the requested type existsConfirm the fix
Re-translate the corrected path and confirm exactly one target comes back, then read its BrowseName and HasTypeDefinition to prove it is the node you intended.
Stop it happening again
Construct browse paths from resolved namespace indices, set reference type and direction explicitly on every element, and keep a per-machine record of which optional members are actually present.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.