fleetd #612 Unit B1: CompletionResolver behavioural test (replaces source-text guard) #627
Reference in New Issue
Block a user
Delete Branch "worker/612-b1-completion-457459-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
fleetd #612 step 2, Unit B1 — CompletionResolver wiring.
Base branch: worker/fleetd-612-unita-87807e-1 (per brief; NOT main).
What changed
Replaced
FleetdCompletionResolverWiringTest.java(4 source-text tests readingFleetd.java's literal source and asserting theCompletionResolverconstruction call still named the right arguments) with
FleetdCompletionResolverAssemblyTest.java(2 behavioural tests), deleting theold file in this same commit.
Unit A (
FleetdAssembly.assembleAndStart) moved that construction call out ofFleetd.main, breaking the old tests on a harmless relocation — they provedspelling, never behaviour.
Deleted test -> what it pinned -> replacement
worktreeBranchLookupIsStillPassedAtTheCallSite(8th ctor arg) ->assembledResolverReportsTheMembersWorktreeAndBranchInAFallbackReport: areal git-worktree-provisioned
MemberSession's branch must appear in anoReportMessagefallback (fleetd #241).backendErrorArgumentsAreStillNamedAtTheCallSite,backendErrorPatternsComesFromTheFactory,backendErrorSinkComesFromTheFactory(5th/6th args) ->assembledResolverClassifiesAndCoolsOffOnAConfiguredBackendErrorPattern: aconfigured
errorPatternthe built-in fallback never matches must classifyas FAILED (not COMPLETION), transition the session to BACKEND_ERROR, and
cool the credential off after two distinct targets within the window
(fleetd #201 Unit 5).
Both tests drive the real
FleetdAssembly.assembleAndStart(...)and readFleetdRuntime.completion()— the exactCompletionResolverinstanceproduction uses — through its public
onDelivered/resolveBeforePostActionAPI, with a controllable
ResourcePortsnanoClock standing in for realsleeps. No test reads any
.javasource text.Mutation proof (acceptance criterion 2)
Each behaviour was mutated at its real call site in
FleetdAssembly.java,confirmed RED with the new test alone, reverted (with a
touchto defeatMaven's stale-mtime skip), and confirmed GREEN again:
_ -> null: RED —AssertionFailedErroron the missingbranch=text in the fallback report.backendErrorPatterns) ->BackendErrorPatternLookup.legacy():RED —
expected: <FAILED> but was: <COMPLETION>.backendErrorSink) ->BackendErrorSink.none(): RED —AssertionFailedErroron sessions stayingSPAWNINGinstead oftransitioning to
BACKEND_ERROR.FleetdAssembly.javais unchanged in the final commit (verified viagit diff --stat, empty).Build
Full
mvn -o test: Tests run: 1878, Failures: 5, Errors: 0, Skipped: 0,BUILD FAILURE — down from the lead-measured baseline of 9 (4 deleted here).
The remaining 5 belong to other in-flight workers on this same ticket and were
not touched:
FleetdBackendQuarantineWiringTest,FleetdConnectionIdentityConstructionTest,FleetdFleetAppConstructionTest,FleetdLeadRolloverWiringTest,FleetdLeadSeatWiringTest.Out of scope (spotted, not fixed)
Same source-text-test shape exists in the 5 guard files above, already
tracked as other workers' scope on this ticket.