Skip to content

🐛 - Bugbot reports valid Python 3.14 PEP 758 exception syntax as a collection breaking SyntaxError #831

Open

Description

@efraespada

Is there an existing issue for this?

  • I have searched the existing issues.

An exact search for PEP 758 found no existing issue. This is separate from progress output-contract failures #828, #829 and #830.

Which actions are affected?

Pull Request

Which platforms are affected?

Linux
macOS

Description

Bugbot publishes two medium-severity, 100%-confidence syntax-error findings for valid Python 3.14 exception handlers. One explicitly states that the project requires Python 3.14 but that except Conflict, StorageBusy: is a SyntaxError in that version. PEP 758 added this syntax in Python 3.14 when no as clause is present.

The declared consumer runtime is >=3.14,<3.15, Ruff target py314 and Python 3.14.6 in the executed backend suite. The exact flagged modules compile, collect and execute. The full backend CI passes 1387 tests with 100% supported statement/branch coverage. The reviewer should use the declared version and concrete parser/CI counterevidence before publishing a universal syntax-error claim or suggested change.

Expected: omit these findings for a Python 3.14 project; preserve a genuine compatibility finding when an actually supported older interpreter cannot parse the syntax. Keep required parentheses when an as clause is present. Do not suppress exception syntax findings globally or weaken review gates.

Actual: both findings incorrectly classify the new grammar as Python 2 syntax and claim pytest cannot collect, despite the successful exact-head suite.

Primary sources:

Reproducing the issue

  1. Consumer PR: Implement HA identity, SQLite persistence and verified restoration domus#7; exact analyzed head ead7dde44f57d32d5a42797a811e798d92b36a89.
  2. Review run/job: https://github.com/vypdev/domus/actions/runs/41227372340/job/124614220480; native review 5724201125; check https://github.com/vypdev/domus/runs/124615649060.
  3. Findings: Implement HA identity, SQLite persistence and verified restoration domus#7 (comment) at tests/backend/test_household_commands.py:415, and Implement HA identity, SQLite persistence and verified restoration domus#7 (comment) at tests/backend/test_member_commands.py:407.
  4. Both statements are exactly except Conflict, StorageBusy: with no as clause. Both are valid under the project's required Python version.
  5. Inspect pyproject.toml requires-python >=3.14,<3.15 and Ruff target py314, the Python pin and frozen CI setup. Run Python 3.14.6 compile(Path(file).read_text(), file, 'exec') on both exact modules: PASS.
  6. Run the two test modules plus snapshot tests: 134 passed. The complete exact-head backend job passes 1387 tests: https://github.com/vypdev/domus/actions/runs/41227372378/job/124614220517. Both full CI Check aggregates pass on this exact head.
  7. Minimal semantic reproduction on Python 3.14:
for kind in (ValueError, TypeError):
    try:
        raise kind('sentinel')
    except ValueError, TypeError:
        print(kind.__name__, 'caught')

Both exception types are caught. No parser compatibility fallback is involved.

copilot Version

vypdev/copilot@v3 resolved to 3e7ceea; codex codex-cli 0.166.0, reviewer model gpt-6-luna, smart effort.

Relevant Log Output

2026-10-31T18:07:22.3345747Z Bugbot reviewer completed partition 30/30.
analysisPartitions=30; completedAnalysisPartitions=30; analysisAssignedFiles=204
candidateFindings=3; publishedFindings=3

The two inline findings explicitly claim the modules raise SyntaxError during parsing. The third finding, a stale snapshot schema number in documentation, is valid and was corrected separately in normal commit 9c44195. No claim is made that all findings were false.

Additional context and comments

The analysis completed all 30 code partitions, but overall coverage is separately partial because human-conversation retained 6 of 9 items and omitted 3. We do not treat this as a complete review or merge acceptance. The PR remains unmerged. No Copilot implementation, installed resources, model/configuration, approval gate or language requirement was changed. Valid production/test syntax will not be rewritten just to hide a false positive; the response will cite actual runtime and primary-source evidence.

Suggested regression scope: valid >=3.14 syntax with/without as; a real <=3.13 compatibility target; except*; project runtime/version evidence; contrary successful parser/collection evidence. Live-model false-positive evidence and deterministic schema correctness should remain distinct. No credentials or owner HA identity/session data are included.

Activity

  1. added
    bugSomething isn't working
    bugfixSomething isn't working
    priority: highCritical issue, needs immediate attention.
    on Oct 31, 2026
  2. added theissue type on Oct 31, 2026
  3. moved this to Todo in vypdevon Oct 31, 2026
  4. changed the title [-]Bugbot reports valid Python 3.14 PEP 758 exception syntax as a collection-breaking SyntaxError[/-] [+]🐛 - Bugbot reports valid Python 3.14 PEP 758 exception syntax as a collection breaking SyntaxError[/+] on Oct 31, 2026
  5. vypbot commented on Oct 31, 2026

    @vypbot
    Contributor

    Hi! I’m @vypbot, the Copilot assistant for this repository.

    I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.

    Try /copilot help to see the available commands, or mention @vypbot with your question.

  6. efraespada commented on Nov 1, 2026

    @efraespada
    MemberAuthor

    Repeated false positive on Domus PR #14 after a complete current-head review

    This is another instance of #831, not a new issue or a request to weaken review gates.

    • Consumer: vypdev/domus PR #14, exact head 2207bca2f13dedee7cf61372eae711765c1bb911.
    • Original review run/job: 41293850399 / 124810467253, check 124811492043.
    • Published finding: discussion_r4435095010, backend/src/domus/application/task_reviews.py:117; medium reliability, confidence 100%.
    • Exact clause: except InvalidInput, TypeError, ValueError:, with no as clause.
    • Finding claims this is invalid Python 3, causes parsing/import failure through the task command/query chain and prevents HTTP startup. It even cites the project's Python >=3.14 requirement as evidence against the syntax.

    That parsing claim is false for the declared runtime. Both root and backend require >=3.14,<3.15; Ruff targets py314. PEP 758 explicitly introduces unparenthesized exception lists without as in Python 3.14.

    Independent checks against the exact unchanged source, using the locked local Python 3.14.6:

    1. ast.parse(source, filename=actual_path) passes.
    2. importlib.import_module("domus.application.task_reviews") passes and resolves to the actual consumer source.
    3. Raising actual InvalidInput, TypeError and ValueError under that unparenthesized clause catches all three as expected.
    4. Exact-head hosted backend jobs already execute 2,899 tests with all 7,605 statements / 2,146 branches covered; the independent complete-source audit passes. The latest ready-for-review-triggered CI Check 124811175716 / run 41293850296 is also green. An import-time SyntaxError cannot explain these executed results.

    This run's review context is actually complete: 106 changed files / 160 diff fragments, all 21 of 21 analysis partitions complete, all reported context sources complete with zero omitted/truncated items. Telemetry reports one candidate and one published finding; it is this syntax claim. This differs from the earlier partial-context observation in the original issue and is not represented as a skipped review.

    The hosted log resolves vypdev/copilot@v3 to 3e7ceea08e6131360e026937d1c0cc1b120472e0; agent codex-cli 0.166.0, reviewer gpt-6-luna, smart effort. Review completed at 2026-11-01T09:41:08Z.

    Please add this source/version/contrary-execution regression to the existing investigation: honor the supported interpreter and verify a parsing assertion with that grammar before publishing 100% confidence. Continue requiring parentheses with as, and preserve real <=3.13 compatibility findings. Do not globally suppress exception-handling review, alter acceptance, or rewrite valid production code merely to silence a false positive.

    We will reply with this runtime/primary-source evidence and resolve the native thread as a false positive, preserving the bot's original comment and review history. No Copilot code, model, prompt, installed resource, marker, policy or verification threshold is changed.

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

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingbugfixSomething isn't workingpriority: highCritical issue, needs immediate attention.

Type

Projects

  • Status
    Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions