Prevent .sqlx files in actions.yaml configs with a clear error

[aicayzer]

Closes #1785.

Problem

Referencing a .sqlx file from definitions/actions.yaml (e.g.

actions:
- table:
    filename: my_table.sqlx

) is unsupported, but the existing code path doesn't say so. The Table/View/etc. constructor reaches nativeRequire(config.filename).query, which fails with a Cannot find module 'definitions/my_table.sqlx' (or equivalently obscure) error far from the actual mistake. As Ekrekr noted on the issue, "this results in strange compilation behavior, and can cause cryptic errors."

Fix

Validate filenames at the loadActionConfigs entry point, before the action is constructed. For each action config sub-message that exposes a filename field — table, view, incrementalTable, assertion, operation, declaration, notebook — if filename ends in .sqlx (case-insensitive), emit a session.compileError naming the action type, the offending filename, and the remediation (use .sql, or rely on Dataform's automatic .sqlx discovery). The action is then skipped so a downstream nativeRequire error doesn't fire on top.

dataPreparation is intentionally excluded: it supports .dp.sqlx files via its own loader (core/actions/data_preparation.ts).

Test plan

Added one new test suite to core/main_test.ts (".sqlx filenames in actions.yaml are rejected with a clear error") covering:

• One test per affected action type (7 in total), each verifying that a single compilation error fires with the expected message shape.
• One case-insensitive test (filename: table.SQLX).
• One regression test ensuring dataPreparation with a .dp.sqlx filename does not trigger this validation.

tslint --project . passes locally. I wasn't able to run bazel test //core/... locally (a @npm//@bazel/typescript:index.bzl loading error in tools/ts_library.bzl against bazel 5.4.0 on my machine), so the unit tests will be exercised by CI here.

Scope

No proto changes. No CLI wiring. No yargs wrapper edits. Scope mirrors PR #2154 (validation + clear error in core/, +16/-5).

Files touched

• core/main.ts — new actionConfigFilenameIsInvalidSqlx helper called from loadActionConfigs.
• core/main_test.ts — new test suite.

[kolina]

/gcbrun

[kolina]

Sorry, I didn't notice tests are failing with YAML require failed run_core: VMError: Cannot find module './workflow_settings.yaml' before approving.

Can you please rebase on the latest HEAD? I think this error is not related to your changes and was fixed in the latest version

[aicayzer]

No problem at all @kolina, just rebased onto the latest main. Lmk if it's still something.

[kolina]

/gcbrun

[kolina]

Hm, your new test is failing like this

Step #1:         at /builder/home/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/sandbox/linux-sandbox/127/execroot/df/_tmp/e6baaed8819351a8a5cad263fdd5689f/tmp_dir_48/node_modules/@dataform/core/bundle.js:18:54579
Step #1:         at new u (/builder/home/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/sandbox/linux-sandbox/127/execroot/df/_tmp/e6baaed8819351a8a5cad263fdd5689f/tmp_dir_48/node_modules/@dataform/core/bundle.js:18:139849)
Step #1:         at u.configureSqlx (/builder/home/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/sandbox/linux-sandbox/127/execroot/df/_tmp/e6baaed8819351a8a5cad263fdd5689f/tmp_dir_48/node_modules/@dataform/core/bundle.js:18:144800)
Step #1:         at Object.require [as nativeRequire] (node_modules/vm2/lib/setup-node-sandbox.js:171:10)
Step #1:         at requireImpl (node_modules/vm2/lib/setup-node-sandbox.js:90:19)
Step #1:         at VM2 Wrapper.apply (node_modules/vm2/lib/bridge.js:1579:11)
Step #1:         at resolve (node_modules/vm2/lib/nodevm.js:383:21)
Step #1:         at CustomResolver.resolve (node_modules/vm2/lib/resolver.js:121:15)
Step #1:         at CustomResolver.resolveFull (node_modules/vm2/lib/resolver.js:316:16)
Step #1:         at CustomResolver.resolveFull (node_modules/vm2/lib/resolver.js:126:9)
Step #1:     VMError: Cannot find module 'prep.dp.sqlx'
Step #1: 
Step #1:                                                                          FAILED
Step #1: @dataform/core > action configs > .sqlx filenames in actions.yaml are rejected with a clear error > but data preparations still accept .dp.sqlx files

I can't say for sure but I suspect we may need to allowlist it here. I think it wasn't caught because GCP compilation doesn't use vm2 and data preparation is quite unlikely to be used by a lot of CLI users

[aicayzer]

Thanks @kolina. I'll look into it tomorrow.

[aicayzer]

Thanks @kolina. I dug into this and the data preparation case turned out to be a bit of a red herring.

Referencing a .dp.sqlx from actions.yaml doesnt actually work today: the filename isnt resolved relative to the config file (hence the Cannot find module), and even when it does load it ignores the file's own config {} block and double-registers the action, since .dp.sqlx files are already auto-compiled from definitions/. So rather than allowlisting it in the vm2 resolver, I dropped the data preparation exception entirely - actions.yaml now rejects .sqlx filenames for every action type, data preparations included, with the same clear error pointing people at auto-discovery. .dp.yaml data preparations are unaffected.

Updated the test to assert the rejection instead. Green locally (//core/... + tslint).

[kolina]

/gcbrun

[kolina]

Sorry for the late response, LGTM.

I left a couple of comments. Feel free to address them if you want, otherwise I'll be happy to merge this PR

[aicayzer]

Thanks @kolina. Dropped the dynamic as any cast for a static list of the typed sub-configs, following the L143 pattern. Green locally on //core/... (16/16) + tslint.

Left the helper name as actionConfigFilenameIsInvalidSqlx since it reads clearly, but happy to switch to actionConfigIncludesSqlxFiles if you'd prefer.

[kolina]

/gcbrun