Repository navigation
🐛🧑💻 - Bugbot predicts failing test despite indirect participant binding and passing typed fault assertion #738
Description
Is there an existing issue for this?
- Searched existing open issues for participant-scope-failure. No matching report. 🐛🧑💻 - Bugbot misidentifies Exposed SQLException inheritance despite compiled artifact and real SQL fault evidence #736 concerns inherited SQL exception handling; this fixture concerns an indirect projection call and an incorrect deterministic test-failure claim.
Which actions are affected?
Pull Request
Which platforms are affected?
macOS (actual local JDK17 test verification); the finding is published by the GitHub PR review action.
Description
Bugbot reports that a parameterized test necessarily fails because getSession allegedly never calls the stubbed participantSession projection. The full call path does call it, and its Left(DatabaseException) propagates to the asserted result. The existing test passes. An additional explicit MockK coVerify proves the indirect call without changing getSession, its invocation branch, the mock outcome or the expected exception.
Finding: vypdev/vaultstadio#113 discussion_r4384726470, medium/reliability, stated confidence100%. Fingerprint fp-13894a84; semantic sf-469f9355; finding_id CollaborationReturnedStateTest:148:participant-scope-failure-falls-through. The finding proposes changing the tested operation; that would lose the intended getSession failure-path contract.
Expected: follow the actual authorization/binding calls or ask for verification when uncertain. Actual: a concrete always-failing-test claim contradicted by execution and the existing production call graph. This report does not assert that all review findings are false: the independent owner-write race, decoder compatibility and inclusive operation-history findings were separately reproduced and fixed.
Reproducing the issue
Use immutable consumer revision bfdfb95c77453559e9da73c3cddce62886fc55a1:
- CollaborationReturnedStateTest enumerates participant-scope-failure, stubs scopes.participantSession to return Left(DatabaseException), invokes service.getSession via its fallback and expects that typed Left.
- CollaborationService.getSession calls access.session and maps the resulting bound session.
- CollaborationAccess: session calls readSession; readSession calls bindSession; bindSession iterates each returned participant and calls scopes.participantSession(participant.id). An Either.Left returns directly and propagates through flatMap/map. The fixture returns one participant.
- With Java17, from backend, run:
./gradlew :core:collaboration:test --tests '*CollaborationReturnedStateTest' --no-daemon --max-workers=2- All24 cases pass, including collected ID
C89-RETURN "participant-scope-failure". To enforce the specific observation add, immediately after invoke and before the existing assertion:
if (case == "participant-scope-failure") {
coVerify(exactly = 1) { f.scopes.participantSession(f.participant.id) }
}This passes too; it is now retained as a stronger regression. No production behavior or test invocation was changed to obtain that result.
copilot Version
Installed consumer workflow uses vypdev/copilot@v3. The reviewed consumer profile is schemaVersion2. No assumption about a mutable tag's exact runtime patch version is needed for this source/evidence fixture.
Relevant Log Output
Local complete backend verification f35140d99c103b6826e1df005e224663fc4f0aee:2735tests/0failures/0errors/0skips, including the original24 returned-state cases. Remote immutable c07383b application run 40438483823 independently passes2697backend+1315desktop+1191browser=5203 cases, including the unchanged original participant-scope case.
The additional explicit-call proof was run at local pre-code contract e7bb3b1 with only test additions: core returned-state24/24pass, including coVerify. In the same diagnostic command, two unrelated new operation-history boundary assertions intentionally failed before their fix; that overall diagnostic command is NOT reported as green. Raw XML, original source inputs and execution metadata are retained by the consumer. Current full verification of the later operation fix is still running.
Additional context and comments
No Copilot source/configuration, protection, reviewed nonsecret decision, test exclusion or quality baseline was altered. We are retaining the getSession regression and making its indirect-call guarantee explicit. Please use this as a small typed functional call-chain fixture; distinguish a reproducible missing fault propagation from a stub reached through a helper. Consumer maintainers continue to resolve genuine code findings independently.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]Bugbot predicts failing test despite indirect participant binding and passing typed fault assertion[/-][+]🐛 - Bugbot predicts failing test despite indirect participant binding and passing typed fault assertion[/+]vypbot commentedon Oct 27, 2026
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 helpto see the available commands, or mention @vypbot with your question.efraespada commentedon Oct 27, 2026
Final consumer evidence: b7522dd application CI40445149238 passes2740backend+1315desktop+1191browser=5246 executions with zero failures/errors/skips, independently reconciled from1064 rawXML and immutable artifact digests. The original getSession invocation/production flow is retained and the explicit coVerify participant-session assertion is present. The complete24-case returned-state group passes. The configured review has now resolved the consumer finding; all four consumer threads are resolved and the final-head review has zero active/unknown findings.
This consumer test clarification does not establish an upstream analysis fix; the original indirect-call fixture and contradictory deterministic failure claim remain reproducible from the immutable source in this report. No control, exclusion, threshold or native protection was weakened. Full consumer evidence and exact case inventory: https://github.com/vypdev/vaultstadio/blob/b7522dd0bf3045da7c3c3170487fa4296095f3f0/docs/development/verification/collaboration-authorization-89.json
4 remaining items
vypbot commentedon Oct 28, 2026
Issue closed — historical progress
Current status: closed as completed.
The last estimate is retained below as history. Closure does not certify a new percentage, tests, or branch alignment.
Action required: none for this closed issue. If work continues, reopen the issue; a fresh assessment can update this same card.
Last assessment before closure (historical)
Merge pull request #757 from vypdev/bugfix/738-bugbot-predicts-failin…
vypbot commentedon Oct 28, 2026
Issue closed: synchronization recommendation retired
No branch synchronization is required for this closed issue.
The previous recommendation is historical. Issue closure does not certify that the branches are synchronized.