Release and verify MSSQL GO batch support in the published npm/WASM package

[dvasdekis]

Summary

The published @pondpilot/flowscope-core@0.9.0 package does not consistently handle SQL Server GO batch separators.

A valid SQL Server script containing two batches and a conventional trailing GO produces a PARSE_ERROR:

SELECT 1;
GO
SELECT 2;
GO

The intermediate GO is handled, but the final separator is passed to the SQL parser as though it were an SQL statement. This suggests that the published WASM artifact does not contain the current MSSQL range-splitting behavior, or that final batch-range handling remains incomplete.

The current upstream source appears to contain MSSQL-specific range-splitting work. Please verify that this behavior is covered by tests and included in the published Rust, WASM, and npm artifacts.

Minimal reproduction

Environment:

• Node.js 20
• @pondpilot/flowscope-core@0.9.0
• Published bundled WASM binary
• dialect: "mssql"

Install the package:

mkdir flowscope-go-repro
cd flowscope-go-repro
npm init -y
npm install @pondpilot/flowscope-core@0.9.0

Run this script:

node --input-type=module <<'NODE'
import { createRequire } from "node:module";
import { readFile } from "node:fs/promises";
import init, {
  analyze_sql_json,
} from "@pondpilot/flowscope-core/wasm/flowscope_wasm.js";

const require = createRequire(import.meta.url);
const wasmPath = require.resolve(
  "@pondpilot/flowscope-core/wasm/flowscope_wasm_bg.wasm",
);

await init({
  module_or_path: await readFile(wasmPath),
});

const sql = `SELECT 1;
GO
SELECT 2;
GO
`;

const result = JSON.parse(
  analyze_sql_json(
    JSON.stringify({
      sql,
      dialect: "mssql",
    }),
  ),
);

console.log(
  JSON.stringify(
    {
      statements: result.statements.length,
      issues: result.issues,
    },
    null,
    2,
  ),
);
NODE

Observed result:

statements: 2
issues: 1
issues[0].severity: error
issues[0].code: PARSE_ERROR
issues[0].span: start=23, end=25

The diagnostic message is:

Parse error: Parse error at line 1, column 1:
sql parser error: Expected: an SQL statement, found: GO
at Line: 1, Column: 1

As a control, changing the input to remove only the final separator:

SELECT 1;
GO
SELECT 2;

returns two statements with no issues.

The same failure occurs with CRLF line endings:

SELECT 1;\r\n
GO\r\n
SELECT 2;\r\n
GO\r\n

The issue is also observable in a real Synapse corpus. Running the published WASM package against a multi-file request produced 116 diagnostics whose parser message reported GO as the unexpected token.

Expected behavior

GO is a SQL Server client-side batch separator, not an SQL statement.
Under the mssql dialect, it should be treated as a batch boundary and should never be passed to sqlparser as an individual statement.

The following cases should not produce PARSE_ERROR:

• GO, go, and Go
• Whitespace-padded separators
• LF and CRLF line endings
• A separator with or without a preceding semicolon
• Leading, intermediate, and trailing separators
• Repeated separators
• Files ending with GO

Statements on both sides of the separator should remain separate
statements with correct:

• Source ranges
• Line and column information
• Source-file attribution
• Statement indexes
• Lineage relationships

GO inside a string literal, line comment, block comment, or bracket-quoted identifier must not be treated as a separator.

Requested changes

1. Add regression tests for MSSQL batch splitting, including:

   • SELECT 1;\nGO\nSELECT 2;\nGO
   • LF and CRLF variants
   • Leading and repeated separators
   • Separators with and without semicolons
   • GO inside strings and comments
   • Multiple files containing independent batches

2. Verify that the fix is used consistently by:

   • Normal analysis
   • Best-effort parsing
   • Statement splitting
   • The native CLI
   • The WASM API

3. Add an integration test that runs against the generated WASM artifact.

4. Publish versions containing the fix for:

   • flowscope-core
   • flowscope-wasm
   • @pondpilot/flowscope-core

5. Re-run the reproduction above against the published npm package and
   confirm that the result contains two statements and no
   PARSE_ERROR.