Deploy Errors#

If your app is usable by other people (Invite-Only, Pending, or Public), a series of checks will occur when you deploy/replace the app with a new version. This is to avoid situations that may cause existing Live Zaps to stop working, or will put Paused Zaps into a corrupted state which causes them to fail when turned on.

Here are some of the commonly encountered issues, and their solutions:

You cannot add this required field without a previously matching field (by key).#

This means that you're adding a new required field, and it's possible that the existing Zaps don't have a value for that field (and thus, the Zaps may break).

If this is a field in a Trigger, Action, or Search, there are three solutions:

  • Leave the field as "optional", and use Scripting for Triggers or Scripting for Actions to set a value if the user left blank in their Zap.

  • If the Zaps are your own (or a co-worker's), and the quantity is "very small", try deleting the Zaps that are using this Trigger/Action/Search, then wait for the stats to re-cache (they're cached every midnight UTC), then retry the deployment.

  • Copy the Trigger/Action/Search and give it a new key (like appending _v2 on the end), add your required field to the new Trigger/Action/Search, and hide the previous Trigger/Action/Search. That way existing Zaps will continue to work with the previous (and now hidden) Trigger/Action/Search definition, and new Zaps will be forced to provide a value for the required field.

If this is a field in your Authentication: This is a pretty big change, because it means that all of the accounts that your users have already setup won't work with the app.

There are two solutions:

Do not remove this trigger/action/search! Be sure its key matches a trigger/action/search in the new app if you did not remove it.#

The Triggers, Actions, and Searches are identified by their key, so if you remove it, or change its key, this message appears.

There are two solutions:

  • If you need to remove a Trigger/Action/Search, change its visibility to hidden instead.

  • If you've renamed the key for a Trigger/Action/Search, you'll need to switch it back to the previous key.

You cannot change an existing trigger's data source (Polling, RESTHooks, etc).#

A change like this will cause your user's Zaps to stop working.

There are two solutions:

  • If the Zaps are your own (or a co-worker's), and the quantity is "very small", try deleting the Zaps that are using this Trigger, then wait for the stats to re-cache (may take an hour), then retry the deployment.

  • Copy the Trigger and give it a new key (like appending _v2 on the end), change the data source of this new Trigger, and hide the previous Trigger. That way existing Zaps will continue to work with the previous (and now hidden) Trigger definition, and new Zaps will use the new Trigger definition.

You cannot change the auth type.#

The existing app uses an authentication type (like Basic Auth, API Key, or OAuth), and your new app uses a different authentication type. This is a pretty big change, because all of the accounts that your users have connected up will stop working for their Zaps.

The typical solution is to take your new app and put it into "Invite Only" status, or submit it for "Public Activation", and then contact us and ask us to "hide" the previous app.

Deduplication comparison for triggers errored.#

If your app contains triggers that use "polling", our system performs a test to ensure that the new version of your app returns the same set of information as the existing/current app.

The way that is determined is that our system will randomly select a set of Zaps (that are turned "on") and are using your app's polling trigger. Our system runs the "polling cycle" using the current app, and the new app, and then compares the set of ID fields returned by both. If they don't match (or an error occurs when testing the newer trigger), then the deployment is halted, and an e-mail is sent to the owner of the app.

Some common issues that may cause this:

  • If you change the "limit" or "page size" of the data returned. For example, if your trigger was previously receiving 100 records, and the new version receives 1000 records, that will cause the test to fail. If you need to make this kind of change, we will need to "pause" all of the Zaps using the trigger(s), perform the deploy, and then "resume" all of those Zaps (so that they'll "see" the "new" set of IDs/objects, and will use that as the baseline for future polling).

  • API Rate limits. If your endpoint has a limit on the quantity of calls that may be performed within a small span of time (like "one API call per second"), the polling test will succeed when testing the existing/current trigger, but will hit that limit when testing the new trigger.

  • Reading data "deletes" it. If your endpoint provides information so that it can only be "read once" (like an activity log), this will cause the test to fail, because the polling cycle with the newer trigger will receive an empty set of data. Polling triggers cannot be used for this kind of purpose.

Other errors or special situations?#

If you have additional questions or concerns, please contact us.

↑ Was this documentation useful? Yes No
Get Help