Articles in this section

Troubleshoot ILM revision and pull issues

Kathyana Queeman

This article helps you diagnose and fix common Integration Lifecycle Management (ILM) problems with revisions, pulls, and merges. Find your symptom in the list, then follow the cause, resolution, and prevention for that issue:

Failed revision status

Symptoms

A Failed revision status shows up in one or both of these ways:

  • A revision row in Revisions shows a Failed status after you attempted a revert.
  • A pull or revert operation started but did not complete, and Revisions shows the operation as Failed rather than Completed.

Causes

A Failed revision status occurs because of one of the following:

  • Deprecated features in the target revision — The revision you are attempting to revert to contains features or functions that integrator.io no longer supports. This is the most common cause of a Failed status.
  • Network issue — The revision operation failed due to a transient network error. This cause is rare.

Resolution

  1. Select an environment at the top of the page.
  2. Go to Home, and then select the integration.
  3. Select Revisions.
  4. Identify a different revision to revert to — one created before the deprecated feature was introduced.
  5. Select Actions (...) on that revision and select the revert option for that revision type: Revert to this revision for a snapshot, or Revert to after this revision or Revert to before this revision for a pull or revert.
  6. Complete the revert in the Create revert, Review changes, and Revert changes panels. See Revert changes.
  7. Verify the revert completes with a Completed status.

Note: If every available revision fails, the deprecated feature may be present across all revisions. Contact Celigo support for assistance.

Note: You can't retry a revision with a Failed status. Create another revision instead.

Prevention

A Failed status caused by deprecated features is a platform constraint — the revision cannot be changed after it's created. To reduce the impact, test reverts in a non-production environment before applying them to production, and pull updates regularly rather than letting large gaps accumulate between revisions.

Unexpected Removed and New actions in Review changes

Symptoms

Unexpected Removed and New actions show up in one or more of these ways:

  • The Review changes panel during a pull shows an existing export, import, or flow listed twice — once as Action: Removed and again as Action: New — instead of a single Action: Update entry.
  • The same component name appears in the Review changes panel as both removed and added, and you did not intentionally delete or recreate that component.
  • Existing flows appear as Action: Deleted paired with Action: New rather than Action: Update.

This is different from components you intentionally deleted or added. When the same component name appears as both Removed and New in one pull, something has gone wrong, and you can't resolve it as a conflict. If you instead see a conflict warning on a resource, see Resolve conflicts.

Cause

This issue occurs when integrator.io can no longer match a component in the remote integration to its counterpart in the current integration. When that happens, it treats the component as deleted from the current integration and new in the remote — rather than updated. The match breaks when multiple significant structural changes accumulate in the remote integration between pull revisions — such as renaming exports or imports, recreating components, or making several large changes at once.

Resolution

Important: Do not proceed with a pull that shows this pattern. Continuing may delete flows, create duplicates, and leave your production integration in an inconsistent state that is difficult to recover from.

  1. Stop — do not proceed with the pull.
  2. Do not delete your existing production integration. It may share components with other integrations or clones, and deleting it prematurely can cause additional data loss.
  3. Select your remote environment (for example, Development) at the top of the page.

  4. Clone the remote integration into the current (Production) environment to create a fresh clone.

    Important: Re-cloning resets the integration's revision history in the target environment. Previous revision history doesn't carry over to the new clone.

  5. Make a minor change in the remote integration.
  6. Create a pull from the remote integration to the new clone.
  7. Verify the Review changes panel shows Action: Update, not Removed and New, for the changed component before proceeding.
  8. Use the new clone as your production integration going forward.

Prevention

Make small, incremental changes in your remote integration between pull revisions. Avoid renaming, recreating, or significantly modifying several exports, imports, or flows at once before pulling. Smaller, more frequent pulls reduce the risk of unexpected Removed and New actions.

Resource removed in Remote and replaced in Current

Symptoms

A removed-and-replaced resource conflict shows up in these ways:

  • The Review changes panel shows a conflict, and the conflict count is greater than 0 conflicts.
  • The same resource is listed with different actions on each side — for example, removed in Remote and replaced in Current.

In the Review changes panel, Current is the integration you are pulling into, and Remote is the integration you are pulling from.

Cause

This conflict occurs when your current and remote integrations have both made changes to the same resource. For example, if the remote integration removed an import and the current integration replaced the same import, the pull can't resolve the mismatch automatically and surfaces a conflict.

Resolution

  1. In the current integration, remove the resource (for example, the import) that appears as replaced in the diff. This makes both integrations consistent.
  2. Pull from the remote integration again, and confirm the conflict count shows 0 conflicts before you merge.

Note: Adding the import back on the remote integration to match the current integration is not recommended. Make the fix in the current integration.

Prevention

Make changes to only one integration between pulls, and coordinate with teammates before removing or replacing shared resources.

Merge fails after edits to both integrations

Symptoms

A merge failure after changes to both integrations shows up in one or both of these ways:

  • A pull fails during the merge step after changes were made to both the original integration and a clone derived from it.
  • A merge that previously succeeded now fails with no obvious change to the integration.

Cause

This issue occurs because ILM's pull and merge functionality requires that only one of the two related integrations (the original or the clone) is modified between pulls. If you make changes to both the original integration and the clone, integrator.io can't reconcile the divergent histories, and the merge fails.

Prevention

If multiple team members are working on related integrations, coordinate so that only one integration is modified between pulls. See Best practices for Integration Lifecycle Management (ILM) for team workflow recommendations.

Merge fails after a pull with a connection error

Symptoms

A merge failure from a connection error shows up in these ways:

  • The pull fails at merge with the message The merge of your pull was unsuccessful. Try your pull again.
  • The remote integration recently removed a connection.

Note: This issue may not be visible during the Review changes step. The merge failure occurs after you attempt to complete the pull.

Cause

This issue occurs when a clone was installed with two remote connections mapped to the same current connection, creating a one-to-many connection linkage. If the remote integration later removes one of those connections, the pull fails at merge.

Resolution

  1. In the current integration, find the import step that still references the connection being removed.
  2. Replace that connection with a new or correct connection.
  3. In the remote integration, select Revisions > Create pull, and select the current integration as the integration to pull from. This reverses the pull direction to bring your connection fix back into the remote.
  4. In the Review changes panel, confirm that the removed export and its old connection no longer appear, and that the import step references the new connection.
  5. In the Merge changes panel, on the connection step, select Configure and select the intended connection.
  6. Complete the merge.
  7. To align both sides, create a pull in the original direction: open the current integration, select Revisions > Create pull, and select the remote integration. This ensures connection linkages are consistent for future pulls.

Prevention

When installing a clone, configure a separate, distinct connection for each remote connection. Do not reuse the same connection for more than one remote connection.

API version difference blocks a pull

Symptoms

An API version difference shows up in these ways:

  • Your integration contains APIs, and the Review changes panel shows a version difference on an API even though you made no API changes.
  • The pull doesn't complete, or the merge fails, while that version difference is present.

This is most common when pulling between environments (for example, from Production to a development environment).

Cause

This is a known limitation. When you pull an integration that contains APIs between environments, the Review changes panel can show a change to the API version field even when no API changes were made. The pull can't complete while that difference is present.

Resolution

  1. Select Revisions > Ignore fields during pull, and add the version field for APIs to the ignore list. See Ignore fields during pull.
  2. In the Review changes panel for the open pull, select the refresh icon. You don't need to create a new pull.
  3. Verify the version difference no longer appears in the Review changes panel and the merge completes with a Completed status.

Prevention

If your integration contains APIs and you pull between environments, add version to the ignore list in Ignore fields during pull before you create the pull.

A pull or clone fails because of the topic limit

Symptoms

A pull, a promotion, or a clone into another environment fails with an error about the topic limit. Nothing in the target environment changes.

Cause

The pull or clone would create topics in the target account, and creating them would put the account over its topic limit (20 by default). A topic that already exists in the target environment is reused and isn't created again, so it doesn't count toward the limit.

Resolution

  1. Delete topics you no longer use in the target account, or contact your Celigo account team to raise the limit.
  2. Run the pull or clone again.

Prevention

Before you pull or clone an integration that contains topics into another environment, check how many topics the target account already has. See Topics.

Known limitations and constraints

  • Shared references change every integration that uses them. Check the References list before you merge; see References.
  • Conflicts from individually modified clones. If you have made changes to each clone separately, you may encounter conflicts when pulling. You can't continue a pull until you resolve all conflicts in the Review changes panel. See Resolve conflicts.
  • Changes made after a pull starts appear after a refresh. See Refresh.
  • Lookup cache data isn't managed by ILM. After a pull, merge, or revert, repopulate lookup cache data before you run any flows; see Lookup caches.

Related articles