fix(validations): avoid ENGINE != InnoDB false positives on row data

[WRasada]

Problem

SQL validation rejects dumps whose table definitions are 100% InnoDB:

Error:  SQL Error: ENGINE != InnoDB on line(s) 97050126, 97055282, ...
SQL validation failed due to 1 error(s)

The flagged lines are INSERT row data — user content that happens to contain strings like engine = (form-submission spam, post content such as "Bigger engine = lower price", etc.). Any sufficiently large real-world dump trips this and is forced to --skip-validate, which also disables every other check.

Root cause

The matcher (trunk permalink) is unanchored and case-insensitive:

matcher: /\sENGINE\s?=(?!(\s?InnoDB))/i,

It fires on engine = anywhere in any line, including inside multi-megabyte INSERT statements.

Fix

Skip lines holding row data — INSERT/REPLACE statements and (...) / ,(...) VALUES rows (both mysqldump extended-insert and mydumper row formats). ENGINE clauses only matter in DDL:

matcher: /^(?!\s*(?:INSERT|REPLACE)\b|\s*[(,]).*\sENGINE\s?=(?!(\s?InnoDB))/i,

Genuine violations still flag: ) ENGINE=MyISAM table definitions, ALTER TABLE ... ENGINE=MyISAM conversions, and the existing fixture's commented-out definition (line 14 expectation unchanged).

Testing

• Regression lines appended to __fixtures__/validations/bad-sql-dump.sql (an INSERT and a mydumper-style ,(...) row containing engine-like strings) + new assertion that they are not flagged
• Existing line-14 expectation still passes
• Verified against a 126M-line production-scale dump: 0 false positives after the fix (16 before), with all 201,721 genuine ENGINE=InnoDB definitions still scanned

Changelog Description

Fixed

• Fixed a false-positive ENGINE != InnoDB SQL validation error triggered by row content containing "engine =" strings

Related

• Refs PLTFRM-728 (same false positive, previously closed without anchoring the matcher) and PLTFRM-2430 (same bug class for USE statements)
• Companion PRs: fix(dev-env): use -o so myloader drops existing tables before import #2871 (myloader -o fix), fix(dev-env): recompute mydumper section sizes after search-replace #2872 (search-replace size fix), perf(dev-env): tune local database performance defaults #2874 (DB tuning)

🤖 Generated with Claude Code

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

This PR fixes a false-positive in the SQL validation rule that reports ENGINE != InnoDB by ensuring the matcher doesn’t trigger on row-data lines (e.g., INSERT/REPLACE statements and ,(...) continuation rows) where user content can contain strings like "engine =". This improves validation reliability on large real-world dumps without weakening the intended DDL-focused enforcement.

Changes:

• Updated the ENGINE != InnoDB regex to ignore row-data lines while still flagging non-InnoDB engines in DDL.
• Extended the bad SQL fixture with row-data lines containing engine-like strings to reproduce the prior false positive.
• Added a regression assertion ensuring only the intended offending line is reported.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/lib/validations/sql.ts	Anchors and refines the ENGINE != InnoDB matcher to skip row-data lines, preventing content-based false positives.
__tests__/lib/validations/sql.js	Adds a regression test asserting row-data “engine =” strings do not add extra flagged lines.
__fixtures__/validations/bad-sql-dump.sql	Appends INSERT/VALUES-row examples containing engine-like strings to validate the new matcher behavior.