Enable fallback

Reference remote tasks, views, resources, and config variables from Studio locally.

By default, any task referenced by a view or another task must be registered when the studio starts up. Additionally, any resource or config variable utilized by a task or built-in must also be configured locally.

However, there are scenarios where you may not want to use local tasks or resources. For example, you may want to:

Execute a task or built-in against a real database.
More quickly test changes by not needing to boot local versions of your resources.
Locally test a task or view without having to configure the tasks they rely on.

In these cases, you can enable fallback behavior to indicate that you'd like to execute a task or reference a resource in a remote environment.

Local tasks, resources, and configs will always take precedence over remote ones, even if a fallback is enabled.

Enabling fallback

To use fallback, open the Studio settings by clicking the gear icon in the bottom left of Studio. Then, make sure the Enable fallback setting is toggled—this will allow remote execution in the currently selected environment:

While this option is enabled, you can switch the environment that remote execution occurs in by changing the selected environment in the Studio header:

To disable fallback behavior, simply toggle the setting off. Studio will remember the option you've selected, even if you restart the dev server.

Remote tasks

Tasks can be referenced from both Views and other tasks. If fallback is enabled and a task has not been registered with the studio locally, then that task will be executed remotely in the currently selected environment.

Any tasks executed remotely will have an indicator next to them:

Note that local tasks can execute remote tasks, but not the other way around. Once a task has been executed remotely, any other tasks it executes will also be executed remotely even if those tasks have been registered locally.

For example, consider the following scenario:

The environment is set to production.
Tasks A and C are registered locally.
Tasks B and C are deployed remotely in production.
A executes B, and B executes C.

When A runs, the studio will detect that B is not registered locally, and attempt to execute B remotely. When B runs, C will also execute remotely, even though it was registered locally with the studio, since remote executions are not aware of any local tasks.

Remote resources

When executing a built-in or a task that uses a resource (e.g. a SQL or REST task), the studio will look for a locally configured resource. If not found and fallback is enabled, the studio will then look for it in that remote environment.

Remote resources will be shown alongside local resources in the resource tab of the studio:

Any built-ins that have been executed remotely will have an indicator, similar to remote tasks:

Remote config variables

If executing a task that uses config variables, the studio will look for those configs variables in the dev config file. If fallback is enabled, the studio will look in that remote environment if it doesn't find the given config variable in the dev config file.

Remote config variables will be shown alongside local config variables in the config variables tab of the studio: