lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(wolf): checkpoint buglog.json (1062 bugs)

Browse source 
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AgYRU3zDTqNGV5Jk8aiKLg
This commit is contained in:
Rongsong Shen 2026-08-27 08:27:43 +00:00
parent 13246a89c8
commit d8bf8fb2e1
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
27 changed files with 7702 additions and 897158 deletions
Download patch file Download diff file Expand all files Collapse all files

20
.claude/skills/xce-audit-invariants/SKILL.md
View file

@ -114,6 +114,26 @@ have historically found real violations are:
reported fact entries are explicitly EXEMPT from the commit-first rule
(pure Raft semantics, retained/retried indefinitely, no commit timeout)
— don't flag those as violations.
9. **Redirect-completeness on role-gated rejections** (new 2026-08-26,
bug-1700) — for every opcode absent from a role's `ha_dispatch_gate()`
allow-list (`ha.c`, e.g. the `CTRL_STANDBY` case's `switch`), does the
generic gate-rejection reply path in `myreq_handler()` (`cluster.c`, right
after the `ha_dispatch_gate()` call) populate `redirect_host`/
`redirect_port` via `fill_redirect_reply()` (`join.c`) when the rejection
reason is `-XCE_ERR_STANDBY`? Every client-side redirect-follower in this
codebase (`xceadmin.discovery.follow_redirects()`, libxce's own failover
path) is already generic/opcode-agnostic and starts working automatically
the instant the server supplies a redirect — a bare rejection status with
no redirect fields silently strands every one of them, and this is a
defect regardless of how well the client is written. This exact gap
shipped independently, under two different opcodes, before either was
caught (`OPCode_upgradeConfig` — found and documented but left unfixed in
`test_e2e_live_ha_push.py`'s module docstring; `OPCode_schedAdmin` —
bug-1700, the one that actually got fixed) — audit method: check the ONE
generic gate-rejection call site first (not opcode-by-opcode), then
confirm every currently-shipped primary-only opcode benefits from
whatever that site does. Also check `api-standards.md`'s "Adding a New
Opcode" step 6 hasn't drifted from what the code actually does.
For `scheduler`, the dimensions are (added 2026-08-24, first used to close
bug-1613/bug-1681 and confirm bug-1611's partial-fix status):