This article covers the problems you are most likely to hit when working with topics — missing messages, messages processed incorrectly, 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 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: The aged-out messages can't be recovered. To prevent it happening again, increase the topic's retention to longer than your worst-case flow downtime. See Choose a retention window.
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, check Used by. See Edits affect every integration.
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 period keeps running while the topic is in the Recycle bin, 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 has never run, edit the listener and set Start from to All retained messages. Once a subscription has run, Start from 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 Topic 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.
Messages were processed incorrectly
Symptom: A flow processed messages but produced wrong results — for example, because of a mapping mistake, a bug in a hook, or a downstream system that accepted bad data.
Cause: A problem in the flow, such as a mapping, hook, or downstream error, processed the messages incorrectly. The flow's position has already moved past them, so they aren't delivered again on their own.
Resolution: Fix the flow, then replay the messages from a time before the problem started. If you know when it ended, select Include end date and time (optional) and enter the end date and time. You can replay only messages still within the topic's retention period.
Duplicate records
Symptom: A subscribing flow processed the same message more than once, creating duplicate records downstream.
Cause: Delivery is at least once, so a message can be delivered again after a retry, a recovery, an interruption, a replay, or a resume from an invalid position. See Delivery guarantees.
Resolution: This is the delivery contract, not a fault. Make subscribing flows idempotent. 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.
A topic can't be deleted
Symptom: Deleting a topic shows: "This topic can't be deleted while flows use it. {{count}} flows still reference it — remove their publish steps and listeners first."
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: "This topic can't be deregistered from this integration while its flows use it. {{count}} flows here still reference it."
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.
- Topic delivery is temporarily interrupted.
Resolution: Confirm the flow is enabled. For sparse traffic, a lone message waits up to the listener's Max wait time before it is delivered — check that setting before assuming a fault.
If delivery is temporarily interrupted, each subscription keeps its position. Nothing within retention is lost, and delivery resumes automatically.
Note: A stalled subscription leaves nothing in the run console or execution logs, so an absence of runs looks the same as an absence of messages. If you can't confirm delivery, check the topic's message history to see whether anything was published.
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.
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 within a batch can still fail, and those failures are reported per message in the response's 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. See Topics API reference.
A pull, promotion, or clone fails because of the topic limit
A pull, a promotion, or a clone into another environment that would put the target environment's account over its topic limit fails before any changes are applied. See A pull or clone fails because of the topic limit.
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.