Note: These compiler changes will only affect connector definitions that are compiled from now on. Any connector definition that was saved and/or submitted before this change was enacted will still run just fine- it will just fail to compile from now on.
Ambiguous Outputs Compiler Change
Why did we make this change?
Back in the early days of the connector builder, our modules were much simpler and provided less information after they were run. This meant that many modules had only one output. This caused many connectors to start using module references using this format: “{{moduleName}}”. This worked for a time, however, as modules grew more complex, many modules began to have multiple outputs. For example, HTTP.Get now has two outputs by default. This means that references like “{{moduleName}}” were now no longer precise enough for our engine to figure out exactly which output was intended by the connector developer. However, we chose to continue to support the less exact reference to support backwards-compatibility, by assuming that general module references were intended to reference that module’s first output.
Over time, we have realized that this can, and does, cause issues at runtime. If a module has been iterated since your connector’s original build, and now has more outputs than at the time of connector compilation, there is a chance that your implied output is no longer the actual output that will be referenced at runtime. As you can imagine, this causes issues, and is not tenable long-term. So, to make this more clear and simple for both ourselves and our users, we’ve decided to stop accepting ambiguous output references.
What does this compiler check test for?
This compiler check will make sure that any module references you make in your connector are referencing an explicit output. If you have a module reference that is only a reference to a module name, with no path specified, your connector definition will fail to compile.
Accepted by compiler:
{{moduleName.outputName}}
Not accepted by compiler:
{{moduleName}}
How do I fix this compilation error?
When you receive a compiler error on Save or Submit, that looks like so:
{
message: "ambiguous output reference (at brick <N>)",
type: "INVALID_SYMBOL",
channelMethod: "<connectorMethodName>",
parent: "path down anonymous Flow stack to compilation error"
}This means that at module number “N” specified in “message” (module numbers can be found next to the name of that module) inside of the method listed under “channelMethod”, you have an ambiguous output reference. This means that you should look for a module reference that looks like this:
{{moduleName}}
and replace it with this:
{{moduleName.outputNameHere}}
If you are working with a legacy V1 module, you will need to replace it with its modern counterpart. For more information about updating modules, see here.
Singular Closing Method Output
Why did we make this change?
Under the hood, methods by design only can have a single output at the end of their operation. This is to make communication between connector methods and user Flows standardized and understandable. As part of this, a “Control.Return” is silently inserted at the end with one input and one output called output. However, if a connector method ends with a module that has more than one output, the connection between the outputs of this last module and the output of the inserted “Control.Return” is ambiguous. This leads to the exact same problem that the “Ambiguous Outputs” compiler change checks for, and therefore must also be controlled.
What does this compiler check test for?
This compiler check ensures that connector methods (Actions, and Functions) end with a module that only has one output. This single output may be an object or list, but it must be a single output.
How do I fix this compilation error?
When you receive a compiler error on Save or Submit, that looks like so:
{
message: "closing method can only return one value at brick <N> <module address>",
type: "INVALID_CLOSE",
channelMethod: "<channel method name>",
parent: "path down anonymous Flow stack to compilation error"
}Or, if the last brick in a connector method has no outputs, like any of the legacy V1 modules, you’ll see a compilation message that looks like this instead:
{
message: "closing method must return one value at brick <N> <module address>",
type: "INVALID_CLOSE",
channelMethod: "<channel method name>",
parent: "path down anonymous Flow stack to compilation error"
}In either case, you’ll likely need an “Object.Construct” or “Control.Let” at the end of a connector method, noted in the “channelMethod” key, with this compilation error, to explicitly tell the compiler what the output of this method is.
If you are using legacy V1 modules in your connector, you may also need to transfer over those modules into their new module counterparts. For more information about updating old modules, see here.