#577: Fix Gherkin importer dropping a scenario after a preceding tagged one

[adityaanikam]

Fixes #577

Root cause

GherkinLineConsumer.readLine() only ends the current scenario (and goes back to looking for the next scenario's metadata) when it sees a Scenario/Scenario Outline/Feature/Rule/Background/Examples boundary line. A @id: tag line matches none of those.

So while a scenario's steps are still being streamed into its description, a @id: tag line for the next scenario falls into the same branch as an ordinary step line and gets appended to the current scenario's description instead of being read as metadata:

if (this.importingScenario)
{
    if (!line.trim().startsWith("#") && !line.trim().isEmpty())
    {
        this.listener.appendDescription(line + System.lineSeparator());
    }
    return;
}
readMetadata(lineNumber, line);

The next scenario is then left without a pending id, and is silently skipped when its Scenario: line is reached (beginScenario bails out when pendingId == null). This only shows up when two tagged scenarios are consecutive — i.e. nothing Gherkin considers a block boundary sits between them — which is exactly why the documented workaround (inserting a throwaway Rule: line) works: a Rule: line is such a boundary.

Fix

dsn~gherkin.streaming-import~1 defines the streaming condition as running "until a Gherkin block boundary", and dsn~gherkin.id-detection~1 requires the @id: tag to be the "immediately preceding" tag for a scenario. A tag line is a boundary in exactly that sense — it's where the next scenario's metadata begins. So a tag line encountered while still streaming a scenario should end the current scenario and be handed to the normal metadata reader, instead of being swallowed as description text:

if (this.importingScenario)
{
    if (line.trim().startsWith("@"))
    {
        endScenario();
        readMetadata(lineNumber, line);
        return;
    }
    if (!line.trim().startsWith("#") && !line.trim().isEmpty())
    {
        this.listener.appendDescription(line + System.lineSeparator());
    }
    return;
}
readMetadata(lineNumber, line);

I also checked the more obvious-looking alternative of adding @ to the BOUNDARY regex, since that's the pattern already used for the other boundary keywords. That doesn't actually work here: the BOUNDARY branch calls clearMetadata() and returns immediately, so readMetadata would never run on that same line and the tag line's own @id: would still never get captured — it would just trade "swallowed as description" for "silently dropped". Ending the scenario and then explicitly falling through to readMetadata for that line is what makes the tag itself get read.

Testing

Added testImportsConsecutiveTaggedScenariosWithoutAnInterveningBoundary, reproducing the issue's exact repro shape (two consecutive tagged scenarios, nothing but a blank line between them), asserting both scenarios import with the correct ids and that neither scenario's description is corrupted by a leaked tag line.

I verified this test fails for the right reason against the pre-fix code (temporarily reverting only the new @-line branch, keeping the test): it fails on all three counts — the second scenario is missing from the result, the first scenario's description is "Given a precondition\r\n@id:scn~second~1" (the tag line leaking in exactly as the root-cause analysis above describes), and indexing the missing second item throws. Restoring the fix returns the suite to green (29/29).

AI assistance disclosure

Per CONTRIBUTING.md's AI-assisted-coding policy: I used an AI coding agent (Claude Code) to help find the root cause of this issue — tracing through GherkinLineConsumer's state machine against the exact reported repro to identify the mechanism. All code changes (the fix and the test) were made manually.

[redcatbear]

Please add a change log entry.

[redcatbear]

Please add a change log entry to 4.10.0.