This article covers the problems you are most likely to hit when working with topics — missing messages, duplicate records, blocked deletions, and subscriptions that appear stalled — with the cause of each and what to do about it. Most of these are expected behavior rather than faults, so knowing the cause usually tells you whether to change a setting or change a flow.
For how topics work, see Celigo Topics overview.
Messages are missing
A flow was off and missed messages
Symptom: A flow was disabled or failing for a period. When you re-enable it, it processes some of the backlog but not all of it, or none at all.
Cause: The messages aged out of the topic's retention window while the flow was down. Retention deletes messages after the configured period whether or not anything read them.
Resolution: You can't recover aged-out messages. To prevent it from happening again, increase the topic's retention to longer than your worst-case flow downtime. See Create and manage topics.
Check the topic's retention against how long your flows realistically stay down — including weekends, maintenance windows, and the time it takes someone to notice a failing flow.
Messages disappeared after a retention change
Symptom: Message history shows fewer messages than it did, and subscriptions can't reach older ones.
Cause: Someone shortened the topic's retention. Messages older than the new window become unreachable.
Resolution: Those messages can't be recovered. Check the topic's audit log to see who changed retention and when. Before shortening retention on a shared topic, use Used by to see which flows depend on it — a window that suits one integration can lose messages for another.
A restored topic has no messages
Symptom: You restored a topic from the Recycle bin. The configuration is intact but there are no messages.
Cause: A topic's retention clock keeps running while it sits in the Recycle bin. The two timers are independent, so a topic restored after longer than its retention period comes back configured but empty.
Resolution: Expected behavior. The messages aren't recoverable.
A new subscription didn't process existing messages
Symptom: You subscribed a flow to a topic that already had messages, but the flow only picked up messages published after you enabled it.
Cause: Start from was left at its default, Only new messages.
Resolution: If the subscription hasn't yet run, edit the listener and set Start from to All retained messages. Once a subscription has run, the field no longer appears, and its position only moves forward with delivery. See Subscribe a flow to a topic.
Published messages never reached a flow
Symptom: Message history shows the messages, but no subscribing flow ran.
Cause and resolution: Check, in order:
- Is the flow enabled? A disabled flow's subscription holds its position and delivers nothing.
- Does the listener point at the right topic? Open the listener and check the Topic field in the Subscription section.
- Is an output filter discarding them? Filtered messages enter the flow and are then dropped, so the flow runs but produces no downstream activity.
- Are the records erroring? Check error management for the flow.
Duplicate records
Symptom: A subscribing flow processed the same message more than once, creating duplicate records downstream.
Cause: Delivery is at least once. A message can be delivered again after a retry, a recovery, or an interruption — and if a subscription's stored position becomes invalid, the platform resumes from the earliest retained message, which redelivers anything after that point.
Resolution: This is the delivery contract, not a fault. Make subscribing flows idempotent so that processing the same message twice produces the same result as processing it once. Common approaches:
- Use an upsert rather than an insert on the destination import.
- Match on a business identifier from the payload so a repeat updates the existing record.
- Set a Concurrency ID lock template so records sharing a key can't be processed at the same time.
Exactly-once delivery isn't offered.
A topic can't be deleted
Symptom: Deleting a topic shows a message that flows still reference it.
Cause: A topic can't be deleted while any publish step or listener points at it — the same rule that protects connections.
Resolution: Select View flows in the dialog to see the flows. Remove the publish steps and listeners in each one, then deregister the topic from every integration, then delete it.
To clear a topic's data without deleting the resource, purge it instead. See View and purge a topic's message history.
A topic can't be deregistered
Symptom: Deregistering shows a message that flows in the integration still reference the topic.
Cause: Deregistration is blocked while any flow in that integration uses the topic — again matching connections.
Resolution: Remove the publish steps and listeners in the listed flows, then deregister. Registrations to other integrations are unaffected.
A subscription appears stalled
Symptom: Messages are being published, but a subscribing flow shows no recent activity in the run console.
Cause: Several possibilities:
- The flow is disabled.
- Messages are arriving sparsely and are still accumulating toward Page size or Max wait time.
- The delivery layer is temporarily unavailable.
Resolution: Confirm the flow is enabled. For sparse traffic, remember that a lone message waits up to the listener's Max wait time before it is delivered — check that setting before assuming a fault.
If the delivery layer is temporarily unavailable, positions hold. Nothing within retention is lost, and delivery resumes automatically on recovery.
Note: In this release, a stalled subscription has no run console footprint — an absence of runs looks the same as an absence of messages. If a flow's messages matter and you can't confirm delivery, check the topic's message history to see whether anything was published at all.
Publishing fails
A record is too large
Symptom: A record fails to publish and lands in error management.
Cause: The mapped payload is larger than the 1 MB per-message limit.
Resolution: Map fewer fields — send subscribers what they need to act, not entire source records. If a record legitimately contains a large array, use One to many with a path to publish each element as its own message.
Publishing is rejected after a license change
Symptom: Publishing stops working and returns an entitlement error.
Cause: The Topics license or trial expired. Publishing is blocked immediately at expiry.
Resolution: Contact your Celigo account team. Topic configuration, registrations, and settings survive an expiry. Retained messages are deleted once the expiry has outlasted the topic's retention window, so history starts empty when the license is restored.
Creating a topic fails at save
Symptom: Creating a topic returns an entitlement error when you save.
Cause: The account is at its licensed topic limit — 20 by default.
Resolution: Delete topics you no longer use, or contact your Celigo account team to raise the limit. The limit is a licensed value that can be raised without a product change.
An API publish drops messages
Symptom: The Topics API returned HTTP 200, but not every message appears in history.
Cause: A 200 means the request succeeded. Individual messages in a batch can still fail, and the response reports those failures per message in the results array.
Resolution: Read the results array, which aligns one-to-one with your request array, and retry only the messages that returned an error.
A topic step arrives unset
Symptom: After promoting or cloning an integration into a different environment, publish steps and listeners have no topic selected.
Cause: In this release, topics don't carry across environments. The operation completes and the topic field arrives unset, deliberately, rather than pointing at a topic in another environment.
Resolution: Open each publish step and listener in the target environment and select or create the topic there.
Within a single environment, cloning reuses the topic the original step pointed at rather than creating a second one. If you want the clone to publish to a different channel, open the cloned step and create a new topic from the picker.
Several flows reset together
Symptom: Changing one flow's subscription behavior affected other flows.
Cause: Those flows share a single listener. A shared listener means one subscription and one position, so every flow using it moves together.
Resolution: Give each flow its own topic listener when they need to move independently.