Block a user
fleetd #519: test policy probe guards
redeploy-fleetd.sh says "no ERROR lines since restart" while blind to the exact failure #493 is about
Part 1 is merged (#522). Part 2 is now unblocked.
The line is live on main:
drain complete: released={N} abandoned={M} (still BUSY at the shutdown deadline)
Grep pattern for part 2…
A test pins the shared SessionManager logger to WARN and never restores it, so any later test asserting an INFO line silently sees nothing
fleetd #512 (part 1): log a positive completion line when drainAll finishes
37dcefa834
Merge #522: log a positive drain-completion line when drainAll finishes (fleetd #512 part 1)
A source-text test pins what a message SAYS and never whether it is REACHED — the drain-gate abort branch can be disabled with the suite green
A source-text test pins what a message SAYS and never whether it is REACHED — the drain-gate abort branch can be disabled with the suite green
Fixed by #520, merged. main is at c71ac23.
I ticked each item of this ticket's own fix section against the merged diff rather than against the worker's report, because a brief can be narrower…
The swap guard can be disabled with the suite green — a "successful" redeploy that never puts the new jar in place
fleetd #517: pin the drain-gate abort branch and jar_id absent case
Nothing tests that FleetMcp uses the CallerResolver — forcing the legacy identity path leaves the whole suite green at 1696/0
Severity: deleting a config key silently downgrades authorization
Raised by the fleet01 lead, and it sharpens the severity line above. I had written this up as "there is an untested branch".…
redeploy-fleetd.sh says "no ERROR lines since restart" while blind to the exact failure #493 is about
Merge constraint on part 1: the completion line must NOT be in a
Merge constraint on part 1: the completion line must NOT be in a finally block
This is an explicit non-goal, raised by the fleet01 lead, and I am recording it as a merge gate rather than…
#505 follow-up: the two-client completeness fold is unpinned, and legacyPrincipal can still re-open the escalation
Correction to the count in my comment above: it is 11 hits, not ten. Re-measured on main at
b37def9:
grep -rn '\.resolved()\
redeploy-fleetd.sh says "no ERROR lines since restart" while blind to the exact failure #493 is about
Independently reproduced on fleet01, and the obvious cheaper fix does not exist
Not my measurement. The fleet01 lead reported the block below from their own host. I have not run any of it;…
probe-member-credentials.sh uses mapfile (bash 4+) with no set -e, so on bash 3.2 it silently reports an empty field list
probe-member-credentials.sh has no test harness at all, and its new arity message is off by one on an empty parse
fleetd #500: honest refusal when the policy parse fails, not just when it's empty
b37def9238
Merge #516: the probe refuses with three distinct messages, each naming its own cause (fleetd #500)
#505 follow-up: the two-client completeness fold is unpinned, and legacyPrincipal can still re-open the escalation