Ignition WebDev Tag Export: Resolve Provider Lookup Errors

Ignition WebDev fails at system.tag.exportTags because the gateway-side call does not resolve the empty tag path the same way the Script Console call does. The gateway log identifies a provider lookup failure; exporting one provider succeeds when its path is explicitly qualified as [default].

Where does the export request stop?

The request path determines which failure to investigate. A Script Console call runs in the client context, which calls the gateway; a WebDev resource executes on the gateway. The two calls therefore do not enter tag export through identical paths.

1. The caller invokes system.tag.exportTags with a tag path and, optionally, a file path.
2. With a file path, the gateway must write to the gateway server's filesystem. The client machine's local permissions and folders do not grant the gateway service access.
3. Without a file path, the function returns an export string, but the gateway still must resolve the supplied tag path to a tag provider.
4. In the reported WebDev failure, provider lookup stops with Provider not found:—the provider name after the colon is blank.

That distinction matters: removing filePath avoids a filesystem write, but it does not fix a provider-resolution failure. Diagnose the error at the hop where it occurs instead of treating every HTTP 500 as a disk-permission problem.

Which symptom points to which cause?

The first row is a plausible explanation for a file-writing failure, not the explanation for the later no-file-path error. The gateway log in this case shows a provider lookup exception inside tag export, so changing filesystem permissions alone will not address that failure.

Which export approach fits the required output?

For returning data to the HTTP requester, omit the file path and return the export result in the WebDev response. For a single provider, explicitly qualify its path. For all providers, do not rely on tagPaths=[""] in WebDev: enumerate provider names using the provider-listing mechanism available in the installed Ignition version, then export each provider separately. Keeping exports separate avoids guessing at the structure required to merge their JSON contents.

Why does Script Console behave differently from WebDev?

Script Console execution and WebDev execution use different contexts. The Script Console runs on the client and calls the gateway; in the observed path, the request is qualified with the project's default tag provider. WebDev executes on the gateway and also applies project-default-provider qualification, but an exportTags bug prevents that qualification from being picked up in this path.

This explains why an empty path can appear to work in Script Console without proving that it exports every tag from every provider. The reported behavior was that the console call exported from the project's default provider, while the WebDev call failed during provider lookup. The issue was described as a bug with a possible fix in 8.3; no installed version or confirmed fix is given here, so test the actual gateway version rather than assuming the empty-path behavior has changed.

Import and export are separate operations. A working WebDev import does not establish that WebDev export resolves providers in the same way; the failing stack trace is specifically in the export path.

How do you configure a WebDev export for one provider?

Use the export string when the endpoint should return data rather than write a server file. The explicit provider path is the operative correction.

def doGet(request, session):
    try:
        tagExportJson = system.tag.exportTags(tagPaths=["[default]"])
    except Exception as e:
        return {
            "json": {
                "success": False,
                "error": str(e)
            }
        }

    return {
        "json": {
            "success": True,
            "data": tagExportJson
        }
    }

This uses the provider path that succeeded in the reported test. Replace it with the exact bracket-qualified name of the provider you intend to export; do not pass a bare provider name such as default. When exporting multiple providers, populate the provider list from the gateway's available providers and call export separately for each qualified provider path. Return a collection keyed by provider name if the endpoint needs to preserve which export came from which provider.

If the endpoint must write to disk instead, retain a server-side file path only after confirming that the directory exists on the gateway host and is writable by the gateway service account. A path such as C:\\TagExports\\tags-export.json refers to the gateway's filesystem in WebDev, not the browser user's filesystem.

How do you verify the gateway export?

1. Call the WebDev endpoint with a single explicitly qualified provider path such as [default], with filePath omitted.
2. Confirm that the response reports success and includes the export string. If it reports failure, inspect the gateway log and distinguish a provider lookup exception from a filesystem exception.
3. For a multi-provider export, verify each provider independently and confirm the returned collection contains the expected provider names and an export result for each.
4. If testing file output, verify the file on the gateway host and confirm the gateway service identity can create or replace it at the selected location.

Do not accept a successful Script Console test as the final check: invoke the WebDev endpoint itself and confirm the expected provider data in its response.

Frequently asked questions