Skip to content

fix: parsing of sql block when there are comments above config block#250

Open
ashish10alex wants to merge 2 commits into
mainfrom
parsing_test
Open

fix: parsing of sql block when there are comments above config block#250
ashish10alex wants to merge 2 commits into
mainfrom
parsing_test

Conversation

@ashish10alex

@ashish10alex ashish10alex commented Feb 12, 2026

Copy link
Copy Markdown
Owner

Summary by CodeRabbit

  • Bug Fixes

    • Fixed an issue where configuration block parsing could be affected by previous SQL block definitions, improving accuracy of file parsing.
  • Tests

    • Added test coverage for SQLX file parsing.

@coderabbitai

coderabbitai Bot commented Feb 12, 2026

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

This PR fixes SQL block state management in the sqlx file parser by resetting tracking variables when entering a config block, preventing state carryover. Corresponding test coverage is added to validate the fix.

Changes

Cohort / File(s) Summary
Parser State Reset
src/sqlxFileParser.ts
Resets SQL block tracking variables (startOfSqlBlock, endOfSqlBlock, sqlBlockExsists) upon entering a config block to prevent prior SQL block state from affecting the current block.
Test Coverage
src/test/suite/extension.test.ts, src/test/test-workspace/definitions/PARSING.sqlx
Adds new test case validating config, preOps, and sql block line indices for PARSING.sqlx; includes test workspace definition file with table resource config, SELECT statement, and pre_operations block.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A parser's memory was cluttered with blocks,
SQL states lingering like forgotten socks!
Now when config enters with a fresh start,
The slate is wiped clean—a tidy code art.
Tests verify all is parsed just right,
Hop-hop—our SQLX shines bright! ✨

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main fix: resetting SQL block tracking when entering a config block to prevent parsing errors when comments appear above the config block.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection ✅ Passed ✅ No merge conflicts detected when merging into main

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch parsing_test

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments
src/sqlxFileParser.ts (2)

60-63: Consider applying the same reset for other major block types.

The fix correctly handles the common case of comments before config {. However, the same misattribution could occur if comments precede a js {, pre_operations {, or post_operations { block that appears before any SQL. For consistency, consider resetting the SQL block state when entering any major block:

♻️ Suggested generalization
         if (!inMajorBlock) {
+            const resetSqlBlock = () => {
+                startOfSqlBlock = 0;
+                endOfSqlBlock = 0;
+                sqlBlockExsists = false;
+            };
+
             if (trimmed.startsWith('config {')) {
                 currentBlock = "config";
                 startOfConfigBlock = i + 1;
                 inMajorBlock = true;
-                
-                // Reset SQL block if we found one before config (likely comments)
-                startOfSqlBlock = 0;
-                endOfSqlBlock = 0;
-                sqlBlockExsists = false;
+                resetSqlBlock();

…and call resetSqlBlock() similarly inside the js {, pre_operations {, and post_operations { branches.


44-49: Brace counting includes braces inside strings and comments.

The brace scanner counts { and } in all positions, including inside string literals (e.g., "tags": ["tag1", "tag2"]) and SQL comments. For the current SQLX grammar this appears safe since config blocks use JS-like object syntax and SQL comments don't typically contain unbalanced braces, but it's worth being aware of as a latent fragility.

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant