What could cause looping in entity updates in D&B integration (Data Blocks)

Question

Entity updates are being duplicated excessively due to a possible loop triggered by a D&B integration recipe. This is causing redundant API calls, excessive job runs, and 429 ("Too Many Requests") errors.

Example
 

• Problem Entity: entityUri=entities/2k2BSqb
• Affected Relation: relations/11HeqES (OrganizationHierarchy, links entities/1PEvGaG → entities/2k2BSqb)
• Observed Behavior: 100+ redundant updates within one minute due to looped integration triggers.
• Unaffected Entity Example: entityUri=entities/2kggwmT (no duplicate updates).

 
Expected Result
Each D&B job submission should result in a single entity update corresponding to the processed DUNS record.
 
Actual Result
The integration process triggered repeated entity updates (~100) within a single execution cycle, causing unnecessary API traffic and potential rate limiting (429 errors).

Answer

Confirm the Scope

1. Check tenant and environment 

2. Identify affected entities and relations from the Activities tab.

3. Note whether duplication affects:

   • Only a specific entity or relation (isolated case)

   • Multiple entities (systemic configuration issue)

Root Cause Isolation Steps

1. Eliminate recipe recursion:

   • Check whether the D&B job that updates an entity also re-triggers itself via PubSub or API callback.

2. Correlate timestamps:

   • Compare the timestamp of updates with job start times to confirm linkage.

3. Analyze surrogate crosswalk logic:

   • Verify the surrogate (e.g., Location.AddressId) is not null.

   • Check if surrogate generation is missing a generateUidWhen rule.

4. Check L3 configuration:

   • Identify whether D&B crosswalks rely on non-unique or nullable attributes.

5. Validate rate limits:

   • 429 responses often indicate looping updates causing API overload.

Solution

Replace the (nonexistent) boolean flags with one generationLogic setting on the DnB surrogate entry.

Current (problematic) entry

{ "enforce": true, 
"source": "configuration/sources/DnB", 
"attributes": [ "configuration/entityTypes/Location/attributes/AddressId" ] } 

Recommended minimal fix

Option A – generate UID if any attribute in the list is missing an OV:

{ "enforce": true,
 "source": "configuration/sources/DnB", 
"attributes": [ "configuration/entityTypes/Location/attributes/AddressId" ], 
"generationLogic": "generateUidWhenOvMissing" } 

Option B – most defensive (covers OV and non-OV missing):

{ "enforce": true, 
"source": "configuration/sources/DnB", "attributes": [ "configuration/entityTypes/Location/attributes/AddressId" ], "generationLogic": "generateUidWhenOvAndNonOvMissing" } 

Option C – only generate UID when all attributes lack an OV:

{ "enforce": true, "source": "configuration/sources/DnB", 
"attributes": [ "configuration/entityTypes/Location/attributes/AddressId" ],
 "generationLogic": "generateUidWhenAllOvMissing" } 

See “Generate surrogate keys with the generationLogic parameter” and the value table in the docs. This page explicitly documents generationLogic (including the accepted values such as generateUidWhenOvMissing, generateUidWhenOvAndNonOvMissing, generateUidWhenAllOvMissing) and how surrogate keys are generated based on that setting and enforce.

Why this scenario occurred (root causes)

The issue was caused by unstable surrogate crosswalk behavior in the integration. Specifically, the configuration in the L3 layer was enforcing a surrogate crosswalk solely on the attribute. Location.AddressId. When this attribute was null or missing, the integration generated new surrogate crosswalks on every run, resulting in a short burst of repeated entity updates (~100 updates).
 

The duplication was not due to recipe or customer misuse, but due to a misaligned surrogate configuration rule that did not account for null-key scenarios. The observed “looping” updates were the downstream symptom of this condition.

1. Unstable Location identity from D&B because the surrogate key can be “empty.”
   In your L3, the DnB surrogate is enforced and built only on Location.AddressId. When D&B creates/updates a Location without AddressId, the surrogate calculation falls back to “no OV present,” which (with default logic) doesn’t produce a stable, unique key. That leads to repeated “new”/mismatched Location references during enrichment, which in turn can re-trigger writes that touch the organization’s hierarchy.

   • Reltio’s Configuring surrogate keys explains surrogate generation and the need to run Recalculate Surrogate Crosswalks when you change logic to avoid collisions/null-derived keys. It also documents the generationLogic options to generate a UID when OVs are missing (instead of hashing empties).

2. The real-time D&B flow then reasserted the same hierarchy link repeatedly.
   Once enrichment fired, the recipe/connector wrote the corporate linkage. Because identity on the address side was unstable and the flow retried/looped, you got many writes on the same relation within ~92 seconds. (Reltio’s D&B docs call out that hierarchy relations are created/updated by enrichment.)

3. Bursting → platform limits → 429s.
   That many POSTs in a short window can hit gateway or endpoint rate/concurrency limits, yielding HTTP 429. (You observed 429s in Jobs around the same minutes.) While 429s are not the cause of the duplicate updates, they are a symptom of the burst behavior.