Best answer

Integration Checks C001

  • 14 January 2021
  • 6 replies

Userlevel 1
Badge +1

The zapier CLI utility on zapier test shows in integration checks result the cd C001 for one of the results and links to .

Unfortunately the documentation does not shed any light on this code C001 - what does it represent? Is it gone or is it new and not yet documented?


Best answer by xavdid 15 January 2021, 00:01

View original

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

6 replies

Userlevel 1
Badge +1

Stumbled over another C code: C003

sample key "Name" in triggers.pitch has been changed/removed (C003) 

The URL leads just to the document without the appropriate anchor.

It looks like these are merely informative to summarize changes to ease review of changes. But would be nice to learn more about the consequences of each of these changes.

Userlevel 2

@toktok sorry about that! The docs are written, but apparently not deployed. the CXXX checks are all very similar and their docs are as follows:

> Try To Avoid Hiding/Removing Public Triggers/Searches/Creates

> During promotion, we compare features of your currently public version with your soon-to-be-public version.

> When you hide/remove a trigger in a new version, Zap Templates that use that trigger become invalid. Try to avoid this when you can. The same applies for searches and creates.


> …

> …

> When you change/remove the `key` property of an item in your `sample`, Zap Templates that use that field become invalid. Try to avoid this when you can.

Userlevel 1
Badge +1

@xavdid Thanks for keeping me in the loop.

C001: We’ve identified early created triggers (and creates) with wrong nouns. That means keys and file-names will change. Any ideas how to mitigate that? I can understand it’s breaking, not so sure if the “key is key”, but from my end it looks like it. Is there any aliasing available perhaps? In any case we’ll tear down the wrong structure and put it under correct names. So from your comment I’d expect that things will break for existing Zaps if they migrate the version.

C003: We’ve identified bogus sample data and removed it. This especially was for keys and these were even without labels. For fields (I’ll just call them this way), is there some kind of fall-back, so that if the key changes but the label stays the same, that the behaviour would be preserved as long as (e.g. as a fall-back) a same named label is found? We tested migrations and it looks like so, but some more information would be nice to know (this is especially about input and output fields. The integration I’m concerned about is with many dynamic fields, and we’ve made the keys much more stable so “client side” renaming fields does not affect the keys any longer, only the labels)

Userlevel 2

It’s worth noting that the Cxxx checks concern Zap Templates specifically. When you promote a new version that fails a C check, some ZTs may be in a bad state. You can work with the partnerships team to fix those. 

As far as live zaps, you’re safe to promote your new version, but may not be able to automatically migrate users between them. That’s ok - by design, it’s fine to leave existing zaps on older versions. Really the only thing that will break a zap is changes to the “key” of a trigger/serach/action or input field (or a coding mistake). Past that, Cxxx checks won’t necessarily affect zaps.

C001: If you’re talking about the actual “noun” field, that’s not used by actual zaps. If you’ve changed keys, you probably can’t migrate zaps.

C003: Sample data doesn’t affect zaps that have already been created. Labels also don’t matter after zap creation (only “key” matters). 

Based on the above, it sounds like you’re good to go, but we’d need to look at your actual changes to be sure. Feel free to write into with your app id if you’d like us to take a closer look.


Userlevel 2

The check docs have been updated:

Userlevel 1
Badge +1

Thanks for the reminder on the Templates and all the other feedback. Very helpful!