Connector functions duplicating on app version revert

When reverting to a previous version of an app, a copy of any connectors used in that app is made, and the reverted app version points to the connector copy. This is not desired behavior, as any changes to the original connector function will not be realized in the app which was reverted.

Is there a setting to turn off this behavior, or can it be disabled for our account? It’s extremely time consuming to have to re-link all of the connectors in the app to the original connector.

Also, ideally, if we’re switching from one connector to another (in this case, fixing the [copy] problem), all of the inputs are wiped and have to be re-input. Would be useful to have logic to check if both connectors have the same number of and type of inputs that it would keep the input fields as they are.

Hey @akbeta -

This is a tricky situation (where we have taken the safest path) but we know it creates some pain, and we are working on a long term fix as we speak.

Challenge -

  • We have a connector with function A, and function A is being used across 3 seperate applications.
  1. When one of these applications is published, the state of Function A is snapshot, ensureing that the published application version will not be impacted by any changes in the editor.
  2. Some change is made to function A (like a change to the payload configuration).
  3. These changes are automatically adopted by all 3 dev versions that are using that function.
  4. When that application version is restored, what should we do?
    4.1 if we want to make sure the restored application works as it did when it was published, we need to also restore the connector function, overriding the changes made in step 2
    4.2 BUT this will mean we also would impact the behavior of all of the other dev versions using that connector, potentially breaking those applications.
  5. The only safe approach is to take that snapshot, and make it into a “copy of” connector, ensuring both the restored configuration, and the dev configuration is maintained. This comes at the cost of now having 2 connectors that need to be managed.

The foundational gap here is that connectors (or their functions) do not expose to users the ability to manage versions, and when restoring we need to expose the user to two seperate versions of the connector (the one being used by apps in dev, and the one being used in the restored application).

The good news is this is an active area of development, and we hope to make this drastically better over the coming few months by adding this true versioning and lineage to connectors. This will allow us to significantly improve restore behavior (because we can have the restored app looking at a different version of the function than the dev apps).

We appreciate the patience - the feedback is heard. If you are interested, I can connect you to our product design team, and we can hop on a call to share some more details of the progress and future solution.

Pete

2 Likes

Thank you Pete, this is helpful to know the background of the decision. We are in contact w/ Hunter on the Product Support Engineering team to find a resolution for this.