Delivery inbox row retirement unblocking #80
Reference in New Issue
Block a user
Delete Branch "%!s()"
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?
Owner goal: latest direct Operations instruction, 2026-10-12: unblock permanent-zero delivery inbox ROW retirement, design state-event retirement proof and implement it; include recovery-block lifecycle and repeated protected-state scanning as related causes. Standard workflow, configured dynamic routing, requested task priority HIGH.
Observable result: an owned isolated synthetic load run advances retired_sequence beyond the first state event and demonstrably reduces eligible agent_delivery_inbox/effects ROW counts while preserving replay, recovery, active/uncertain delivery and required session state. Expired payload count zero alone is not row-retirement success.
This task owns ONE structural row-retirement defect and related proof/block/frontier behavior. Original retention1802f4a9 shipped fork226 and remains passive review/input wait; no live writer was found. Preserve its safety contracts and original unresolved bounded-row outcome. This new owner is the sole row-retirement code writer; do not recreate payload throughput bb57420bd0, sync guards d4f9d10f7b or resume235.
Source baseline: fork236 head3640339d52bfefcf3b27ff6ea6988161832d3af5 is the actual running source (controller verified system/info). It was squash-merged to fork main as3faf596a3e15e7a1d521b0461f5b28e35fa5c1d8 at06:35:05Z. Operations reports web inclusion, A-E normal+dynamic/B-E pass and expired payload rows staying0. These are qualified Operations runtime reports, not this worker's tests and not a proof that row retirement works.
Reported investigation input from Operations/retention analysis atd4f9d10f7b: all59 cursor seq1 events are agent_capabilities, absent from candidates.go:125-134 allow-list and fail events.go payload Ready; prefix-only retirement therefore stays0. Reported influx ~1500rows/min, inbox680146 at06:18Z, DB9.96GB. Open recovery blocks now16; earlier12 protected14221rows/27.7MB. State events capabilities/mode/MCP stay protected and discovery.go:263-271 rescans from the beginning. Preserve timestamps and label these as supplied observations, not newly measured live data. Verify current assigned source and reproduce only this defect safely, never investigate/mutate operating DB/home/settings.
Design BEFORE production/permanent-test changes: owning English requirements/system-design/plan/work-order package, reusing current backend-inbox/durable-delivery contracts. Decide the minimal safe representation of superseded state events (a latest durable snapshot is an EXAMPLE, not an approved arbitrary delete rule), when the retirement proof may advance, and how recovery restoration still reconstructs the required state. Classify recovery blocks as genuinely open versus proven resolved through existing evidence; no blanket age expiry or unprotected deletion. Bound repeated-frontier work without skipping required evidence. Show actual affected files/contract/source callers and compare practical approaches if high risk. Concrete reviewed checkpoint goes to parent before further implementation; generic workflow text does not waive it.
Preserve BOTH raw-payload pruning eligibility and the locked retirement/deletion/reload boundary; a proof valid at discovery must still hold at mutation. Keep compaction behavior, restart continuity, generation/projection/replay cursors, active/uncertain submissions, recovery-required evidence, restore ownership and session capabilities/mode/MCP state. No allow-list-all shortcut merely to make retired_sequence nonzero, no forced cursor advance, no bulk recovery-block clear, no state/history deletion to pass load metrics, no retention-policy weakening. Distinguish safe row deletion from payload pruning and SQLite file compaction/reuse.
Use only ONE Kandev-assigned worktree on fresh fork main containing236. You are not alone: preserve sibling edits/refs and existing verified work. No new native worker/session/task/copy, manual model/order/ceiling, shared checkout edit, force/reset or unmerged destruction. Configured dynamic profile35909ac3, Worktree08eb0bba/new_workspace. The request for HIGH must be actual task metadata, not a title or prose claim; controller has no priority setter MCP and no enabled browser/native UI, so Operations will set it. Do not patch raw API/DB or add a priority tool as part of this fix.
Narrow source-adjacent units for changed retirement/snapshot/block/frontier logic, legitimate protected records versus safely retired state, lock/reload/race and restore continuity. ONE owned isolated synthetic load proof, same branch/offhome TEST via canonical dev-isolated.ps1 and owned pidfile kandev-kill.ps1 -Yes (powershell -File); record before/after row counts, retired cursor advance, retained protected rows and replay/restore outcomes. No real provider/credential/production data, operating DB copy/mutation, direct backend/shared build/global kill/guard bypass or second worktree if the isolation guard refuses. Report the exact unsupported entry blocker instead of bypassing it. No full suites/E2E/CI/new validator/recurring load job/unchanged-success reruns. Keep existing Windows listener exclusions until actual4419 merge+ownsource; tunnel/plugin-fixture/portutil changed-tests only. Reuse sufficient existing tests; SKIP is not PASS.
Fork implementation/review/check/commit/push/PR/merge and exact branch/base/head/delta/actual results go to parent. Installation/operating cleanup is Operations-owned; do not change operating retention settings. If current UPSTREAM has the same structural defect, fork-zero category1: prepare a qualified general delta and hand it to upstream controller93c6b4d0, which coordinates W091-only publication. No worker upstream write or new upstream task/issue. If unsupported, report factual difference without narrowing the fork outcome.
Queue: KANDEV-INBOX-ROW-RETIREMENT-20261012. Report the queue's jobsheet through the existing gate only at reflection/cleanup; no direct AIWS source/ledger/new hash/framework. Keep this one task for all related row-retirement causes, not a task per state type/block or a duplicate of1802. Do not declare the old original retention result complete merely because236 was deployed or payloads expire.