A merged JMeter .jmx no longer opens after two engineers edited it the same day. How do you diagnose it?

Two engineers edited one plan on the same day. One added a sampler to the checkout flow; the other reordered two controllers. The merge resolved without a reported conflict, or with one that looked easy, and now nobody can open the file. This is the most common `.jmx` incident there is, and it has a short diagnosis. ## Step 1: which kind of failure is it? There are two, and they come from different layers. | Symptom | Layer | Typical merge damage | |---|---|---| | JMeter reports an error in the XML format | The XML parser | A conflict marker left in the file, a tag left unbalanced | | JMeter reports `Problem loading XML from:` and a root cause | The JMX converter | Broken element/`hashTree` pairing, a missing `guiclass` | Run the file through any XML well-formedness check first. If it fails there, the fix is textual and obvious — a `<<<<<<<` line, a duplicated closing tag — and you have not yet learned anything about the plan. If it is well formed, the failure is structural and the message names the file and the root cause. ## Step 2: the two structural causes **Broken pairing.** The file is a flat run of alternating pairs: element, its `hashTree`, element, its `hashTree`. The loader toggles between the two on each child it reads. Drop or duplicate one `<hashTree>` in the middle of a block and every later pair is off by one; the next element node is handed to the code that sets a subtree, which casts it to a tree and fails. Check it mechanically: inside each `<hashTree>`, the child count must be even and the tag types must alternate. **A missing `guiclass`.** Every element that sits in the tree must carry `guiclass`; the converter reads it first and throws `guiclass attribute is not found` when it is absent. A hand-pasted element, or one whose opening tag was reassembled from two conflicting sides, is the usual source. ## Step 3: bisect the merge, do not repair it The instinct is to open the merged file in an editor and fix the pairing. Resist it, because a file that loads is not the same thing as a plan that is correct — a mis-paired element that happens to land in a valid position loads happily under the wrong parent. Do this instead: 1. Check out each parent version on its own and confirm each one opens. This tells you the damage is in the merge, not in one side's commit. 2. Decide which side's change is smaller. 3. Take the other side whole — not a merge, the file as it was committed. 4. Re-apply the smaller change in the JMeter GUI and save. The save regenerates a correctly paired file from the in-memory tree. 5. Diff the result against both parents and confirm the only differences are the two intended changes, plus whatever header churn the save introduced. ## Step 4: check for the failure that did not fail The dangerous outcome of a bad merge is not the file that refuses to open. It is the file that opens. Two things to check before you trust the rebuilt plan: - Every `enabled` attribute. A merge can resolve to `enabled="false"` on a Thread Group; the plan loads, the run finishes, and the branch never executed. - The nesting of anything that moved. An element re-paired under a different parent changes what it applies to, and the file gives no warning at all. The general lesson is that this format is safe to *generate* and unsafe to *reconcile*. The recovery is always the same shape: keep one side whole, redo the other in the tool.