Rongsong Shen
b0f2aea466
- buglog: gitea_issue / gitea_synced_status for the 20 bugs created and the 30 already-synced entries (#25/#35 reopened as partial) - .kiro/specs/*/spec.json: "gitea" milestone/issue mapping for all 66 specs (65 milestones + 195 issues created, 158 closed at creation) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
41 lines
5.1 KiB
JSON
41 lines
5.1 KiB
JSON
{
|
|
"feature_name": "ha-entity-snapshots",
|
|
"created_at": "2026-07-01T03:32:11Z",
|
|
"updated_at": "2026-07-18T00:35:32Z",
|
|
"language": "en",
|
|
"phase": "implementation-complete",
|
|
"approvals": {
|
|
"requirements": {
|
|
"generated": true,
|
|
"approved": true
|
|
},
|
|
"design": {
|
|
"generated": true,
|
|
"approved": true
|
|
},
|
|
"tasks": {
|
|
"generated": true,
|
|
"approved": true
|
|
}
|
|
},
|
|
"ready_for_implementation": true,
|
|
"blocked_on": [],
|
|
"validate_impl": {
|
|
"decision": "GO",
|
|
"validated_at": "2026-07-18T00:35:32Z",
|
|
"note": "First post-implementation validation run -- all 21 tasks (1.1-8.1) were already [x] with no prior validate_impl record and phase stuck at tasks-generated (administrative oversight). Pre-check on task 7.1: tasks.md carries a 2026-07-01 'RESOLVED' note and git history (3fab291 block -> f3c86a6/9f4292d/b9ad018/1439e26 resolve) confirms the 2026-07-02-era 'pending upstream snapshot-boundary recon' blocker was genuinely closed, not just checkbox-checked -- it was owned by raft-ha-core-safety task 3 (Snapshot-boundary reconciliation, [x]) / task 5.10a (CLOSED), whose investigation found and fixed four real bugs (walcompare per-member checkpoint-floor false-positive, a delaymgr seconds/ms deadline-type-confusion starvation bug, a hardcoded 64MB WAL-segment-rotation stall, and a netio.h INVOKE_MSG_HANDLER UAF during concurrent snapshot-transfer+election) culminating in a live `--force-snapshot` soak: committed_divergence=0 committed_job_loss=0 result=PASS with a confirmed real 'HA: snapshot' install log line, plus a clean 3-round --chaotic regression. Proceeded to full validation on that basis. Full controller_unit_test suite: meson Ok:3/Fail:0; ANSI-stripped authoritative count (project convention, since meson's summary can mask Unity sub-group failures) = 962 PASS / 0 FAIL, including all 9 dedicated test_persist_snapshot_entities.c cases green. TBD/secrets grep clean (the one 'XXXXXX' hit is an mktemp template, not a TODO; ha.c:1844's stale TODO is a pre-existing, unrelated, already-self-flagged ha-term-safety item, not introduced here). File Structure Plan matches actual files exactly (persist.c, persist.h, ha.h, ha.c, test_persist_snapshot_entities.c) -- no drift, no boundary spillover into any Out-of-Boundary area (wire transport, catch-up decision logic, repl_trim_lsn, worker/join, config-doc snapshotting all untouched). Cross-task integration verified by direct code read: the `out_entities_restored` out-parameter flows persist.h's declaration -> load_snapshot's real implementation -> both consumers (ha.c:3112-3147 wire receive path / task 6.1, persist.c:4277-4285 local boot recovery / task 8.1); `snapshot_inflight_lsn[]` is wired ha.h declaration -> ha.c's 4 set/clear lifecycle sites -> persist.c:2157's rotate_snapshots consultation, matching design.md's Architecture Pattern & Boundary Map diagram exactly. `persist_checkpoint` (persist.c:2262) confirmed to gate `trim_wal_segments`/`rotate_snapshots` on `write_snapshot`'s rc, satisfying Requirement 3 without a new trim-floor variable exactly as design.md's Architecture Analysis argued. All 12 requirements.md line items (1.1-5.2) map through design.md's Requirements Traceability table to a completed task, no gaps. The pre-existing `restore_job` decode leak flagged in tasks.md's Implementation Notes (2.2) is confirmed fixed in task 5.2's commit (9fdb677): `free_Job(&j)` now runs on both the early-EEXIST-return and normal-completion paths in job.c.",
|
|
"known_limitations": [
|
|
"Non-Goal (by design, documented in design.md): zarray copy-on-write entity enumeration is not wired into kvmgr; point-in-time checkpoint consistency instead relies on table-level + per-entity RTTI_LOCK_READ/WRITE nesting during the collection walk. Correct as implemented, just not the eventual lock-free approach research.md's Option B describes.",
|
|
"tasks.md Implementation Note (5.2): restore_queue_state's -ENOENT ('queue not yet built from config') aborts the ENTIRE checkpoint restore, including already-successfully-restored jobs earlier in the same file. This is design-compliant (Requirement 2.3 is unconditional: any restore failure leaves position unchanged) but is a real residual availability risk -- a benign config-lag on the destination member could make catch-up fail outright rather than skip-and-continue. Flagged as a WATCH-ITEM in the spec's own notes if a future catch-up round is observed to stall.",
|
|
"Test-only, non-production: a pre-existing ASan leak in the test fixture itself (snapent_make -> makeInstance/makeJob/makeQueue/xkvmgr_add, ~18KB/113 allocations across the whole test file), masked by this suite's standing ASAN_OPTIONS=detect_leaks=0 convention; and a minor verbatim-duplicated 'skip past job section' loop between snapent_read_checkpoint_jobs and snapent_read_checkpoint_queues. Neither blocks any requirement; both are called out in tasks.md's own Implementation Notes as candidates for a future fixture cleanup pass if the test file keeps growing."
|
|
]
|
|
},
|
|
"gitea": {
|
|
"milestone_id": 20,
|
|
"issues": {
|
|
"requirements_design": 123,
|
|
"implementation": 124,
|
|
"validation": 125
|
|
}
|
|
}
|
|
}
|