Decoding IRE Errors: A Practical Guide to CMDB Identification & Reconciliation Failures

[Dinethri ASP]

If you've spent any real time with CMDB and Discovery, you already know the feeling. You open up ecc_queue or a Discovery status record, see something like MISSING_MATCHING_ATTRIBUTES or ABANDONED staring back at you, and... that's it. No explanation, no hint, just a status string. So you do what everyone does at first: you poke at the identification rule until the red goes away and move on with your life.

I want to save you some of that trial and error, because once you understand what IRE is actually checking, these five errors stop being mysterious and start being genuinely predictable.

What IRE is actually doing

The Identification & Reconciliation Engine has one job: given an incoming payload (from Discovery, a Service Graph Connector, an integration, whatever), decide whether that data matches an existing CI or should become a new one, and whether the source is even allowed to touch the fields it's trying to write.

Every CI class has an Identification Rule made up of one or more identifier entries, each listing which attributes to match on, whether those attributes depend on a related CI, and the priority order to try them in.

Separately, every source has Reconciliation Rules saying which fields it's authoritative for. A source can match a CI perfectly and still get blocked from writing to a field it doesn't own.

Almost every confusing IRE error comes down to one of these two systems quietly failing: identification can't confidently pick a CI, or reconciliation won't let the write happen even though identification succeeded.

 

The five errors you'll actually run into

 

1. MISSING_MATCHING_ATTRIBUTES

This one means the payload doesn't have enough of the attributes the identifier entry is expecting, so IRE can't even attempt a match using that entry.

I've seen this most often when an integration was built against an older, more forgiving version of the identification rule, or the source system just doesn't collect a field for every record it sends. The fix isn't to loosen the rule; that just pushes the problem downstream into false-positive matching later. Go look at the actual payload sitting in the ECC queue or staging table, compare it field-by-field against what the identifier entry wants, and either enrich the source data or adjust the rule to match on something the source can reliably provide.

 

2. MULTIPLE_DEPENDENCIES and MISSING_DEPENDENCY

Here's where I'll tell you about a real one, because this pattern bit me more than once working on cloud CMDB discovery.

I was troubleshooting a batch of cmdb_ci_resource_group records that kept failing identification, and the error was MULTIPLE_DEPENDENCIES. The identifier entry for resource groups matched on name plus a dependent relationship to the parent, in this case something like a cmdb_ci_azure_datacenter or subscription-level CI. The problem was that the payload only sent a resource group name, and names like "rg-prod" or "rg-shared" get reused across multiple subscriptions constantly. So IRE found two, three, sometimes more existing datacenter/subscription CIs that could plausibly be the parent, and it had no way to pick the right one. Rather than guess, it correctly refused.

The fix wasn't touching the identification rule at all; it was fixing the payload to include the full resource path or a unique subscription ID instead of just a display name. Once the parent reference was unambiguous, the conflict disappeared on its own.

MISSING_DEPENDENCY is the flip side of the same coin: the identifier needs a parent CI to already exist, and it doesn't yet. This shows up a lot when child resources get processed before their parents, or when the parent payload itself silently failed identification for an unrelated reason. My advice: when you see this one, don't start troubleshooting at the child record. Walk up the chain first: find the parent, confirm it landed correctly and got classified properly, and the dependent failures usually clear themselves once you fix that and let things reprocess.

 

3. ABANDONED

This is IRE's safety net it means no identifier entry could resolve the payload with confidence, so rather than risk creating a duplicate or corrupting an existing CI, it just gives up.

It's the least specific error you'll see, which makes it the most annoying to debug, because the real cause is almost always one of the other errors hiding underneath it. When I hit ABANDONED, I treat it as a prompt to go check the basics: is a required attribute coming through empty (REQUIRED_ATTRIBUTE_EMPTY)? Is the identification rule for that class even active, or is a duplicate/overlapping rule shadowing it (IDENTIFICATION_RULE_MISSING if there's no rule found at all)? Is NO_IDENTIFIER_KEYS_GENERATED showing up in the same batch  which usually means the payload itself is malformed before it ever reaches matching logic?

There's no single fix here. You trace back to whichever of the other errors is actually the root cause, using the raw payload as your source of truth instead of assumptions about what the integration is "supposed to" be sending.

The habit that saves you the most time

Honestly, the biggest thing that's changed how fast I debug this stuff: read the raw payload before you touch the identification rule. Most of the time spent debugging IRE goes into adjusting rules against a payload nobody's actually looked at. Once you can see exactly what attributes arrived, what class they got tagged as, and what order dependent CIs processed in, most of these errors point straight at themselves.

Second habit: build yourself a small test harness. Instead of waiting for a full Discovery run or integration cycle to reproduce something, insert a payload directly into the staging table or replay a captured ECC queue entry. That turns a 20-minute discovery cycle into a 30-second feedback loop and it's the difference between guessing at a fix and actually understanding the rule you're editing.

 

Takeaway

Every one of these errors traces back to two questions: can this payload be matched to a CI with confidence, and is this source even allowed to write what it's trying to write? Once you're debugging against those two questions instead of the error string on the screen, IRE stops being a black box.

Have you hit a different IRE pattern, or a war story from a large discovery rollout? I'd genuinely like to hear it. This is one of those corners of the platform where every environment teaches you something new.