Relationship events don’t arrive in Pub/Sub after a re-post or re-cleanse, and how to re-emit them

Gloria

Updated November 13, 2026 20:08

Symptoms

You can retrieve a relationship via the API, but no message reaches your downstream pipeline (Pub/Sub, Dataflow, a database) when you re-post it.
Re-posting a relationship with unchanged data returns a response body but produces no event.
A re-cleanse run against relation URIs produces no messages.
The same actions work in a lower environment but not in Production.

Cause

There are two separate causes.

1. Posts that change nothing don’t generate events. Reltio creates an activity log entry and an event only when a post actually changes data. A post identical to the existing data creates neither. A post that changes anything is logged and streamed as RELATIONSHIP_CHANGED. That includes a source crosswalk’s deleteDate, because adding or removing it changes the operational value (OV).

2. Re-cleanse accepts only entity URIs. The Re-cleanse Data task is an entity-level task. If you pass relation URIs (for example relations/0AbCdEf), every part of the task fails within about a second with:

Cannot cast com.reltio.metadata.uri.data.RelationshipURI to com.reltio.metadata.uri.data.EntityURI

No data is processed, and no events are generated. Even with entity URIs, re-cleanse generates no events when the cleanse finds no change, and it doesn’t re-emit relationship events.

How to confirm which cause you have

Check the activity log for the relationship:

GET {TenantURL}/activities?filter=equals(items.objectUri,'relations/<id>')&max=50

An entry means Reltio recorded a change and generated an event. The entry’s eventId identifies it.
No entry means the post changed nothing, so no event was expected.

Don’t rely on GET {TenantURL}/relations/_events for this check. It can return incomplete results.

Check for a failed re-cleanse in the tenant’s task history or in the Tasks view in the Console. Look for a ReCleanseDataTask with status FAILED and the error above, and check parameters.uriList for relation URIs.

Resolution: re-emit relationship events without changing data

Use the Reindex Relations task with a request body that lists the relation URIs:

POST {ApplicationURL}/api/{tenantId}/reindexRelations


["relations/0AbCdEf", "relations/0GhIjKl"]

The task requires the tenant admin role. With a body, the task processes only the listed relations. For each relation in scope, the task reads the relation and emits a RELATIONSHIP_CHANGED event. That event triggers the normal processing pipeline (search index, match tables, analytics) and, with the default settings, is published to your external streaming destinations (AMQ, SQS or Pub/Sub). The stored data isn’t modified and the relation’s version doesn’t change, but the event is still typed RELATIONSHIP_CHANGED.

Keep forceIgnoreInStreaming at its default (false). Setting it to true suppresses publishing to external customer queues.
Keep updateRelations at its default (true). Setting it to false skips the external streaming processor entirely and updates only the search index.
Start with one or two relations (in a lower environment if you have one), then one in Production, before running a larger list.
Allow up to about 10 minutes for delivery. Reltio documents delays of up to that length for events in external queues, and streaming isn’t FIFO.

Don’t

Run the task without a body. It would then cover the relations in the whole tenant, which can generate a very large volume of events. Use relationType to narrow a type-wide run.

Check that your streaming configuration passes the events

The destination’s typeFilter includes RELATIONSHIP_CHANGED.
The destination’s objectFilter allows the relation type.
The tenant-level streamingEnabled and streamingAPIEnabled settings are on. Task events go to external destinations only when streamingAPIEnabled is true.
Every filter expression has balanced parentheses. An unclosed one is easy to miss.

Prevention

To refresh downstream systems, use Reindex Relations with a URI list. An identical re-post is not a refresh.
Don’t use re-cleanse for relationships.
Use the activity log to verify that Reltio generated an event, then check your own subscription to verify delivery.
On the consumer side, set alerts on the Pub/Sub subscription (oldest unacknowledged message age and backlog) and configure a dead-letter topic. Message retention and expiry for Pub/Sub are controlled by your subscription settings.