Phase 3: sync data phase batches are bounded by count, not bytes #180

Activity

1. github-actions

   assigned

   dezren39

   on Oct 12, 2026
2. dezren39 commented on Oct 24, 2026

   

   dezren39

   on Oct 24, 2026

   MemberAuthor

   More actions

   id train triage (2026-10-24): too-big-needs-design — byte bound for the sync data phase; batches are count-bound at 256 regardless of event size.
3. dezren39

   added

   app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   on Oct 27, 2026
4. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   🤖 Agent note · picked up

   • Agent: queue worker (repo-worker-code), lane A
   • Session / ID: queue task 2023
   • Found via: queue claim
   • Task: Triage issue Phase 3: sync data phase batches are bounded by count, not bytes #180 — verify sync data phase batching is count-bound not byte-bound on current main, then route or close with evidence
   • Expectation: s — triage verdict backed by code citation at current HEAD; follow-up fix packet if confirmed
   • Links: issue Phase 3: sync data phase batches are bounded by count, not bytes #180
5. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   🤖 Agent note · done

   • Agent: queue worker (repo-worker-code), lane A
   • Session / ID: queue task 2023
   • Found via: queue claim
   • Task: Triage issue Phase 3: sync data phase batches are bounded by count, not bytes #180 — sync data phase batches bounded by count, not bytes
   • Verdict: CONFIRMED on current main a3cdf6c9a35df1ff8b88b7a02d62e5c04ca4c94a (2026-10-29T01:52Z).
   • Evidence: pkgs/id/src/event_store/sync.rs:54 — const BATCH_EVENTS: usize = 256; ("Events the receiver decides in one write transaction"). receive_data (sync.rs:574+) accumulates pending: Vec<Event> and flushes only when pending.len() == BATCH_EVENTS — no byte counter anywhere in the data phase. Each frame is individually capped at range::FRAME_CAP = 16 MiB (range.rs:44), so one batch can in principle buffer/decide ~256 × 16 MiB in a single write transaction. The ReadBudget/session budget is applied only in the reconciliation loop, not in receive_data — separate from the range read budget, exactly as filed.
   • Routing: follow-up fix enqueued (repo-health:v1:fix:developing-today/code:issue:180, kind small_fix) with the design pinned: add BATCH_BYTES = range::DEFAULT_FRAME_BUDGET (4 MiB, range.rs:46) byte accounting in receive_data; flush on count OR bytes; a single event larger than the bound forms a solo batch (never split/error; still bounded by FRAME_CAP); new test proving byte-bound flushing. Issue stays open, labelled queue/queued for the fix task.
   • Links: issue Phase 3: sync data phase batches are bounded by count, not bytes #180
6. dezren39

   added

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   and removed

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   on Oct 29, 2026
7. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   🤖 Agent note · picked up

   • Agent: queue worker (repo-worker-code), lane D
   • Session / ID: queue task 2971 (small_fix)
   • Found via: queue claim
   • Task: Implement Phase 3: sync data phase batches are bounded by count, not bytes #180 per triage task 2023's pinned design: add a byte bound (BATCH_BYTES = range::DEFAULT_FRAME_BUDGET, 4 MiB) alongside BATCH_EVENTS in receive_data (pkgs/id/src/event_store/sync.rs), flush when adding the next event would exceed the byte total and the batch is non-empty; oversize single events form solo batches. Plus a byte-bound flush test in the same file.
   • Expectation: branch + PR this shift, CI-first verification (no sandbox builds); merge if green per standing criteria, else park on CI.
8. dezren39

   added

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   on Oct 29, 2026
9. 23 remaining items

   Load more
10. dezren39

    removed

    queue/parkedQueue task is parked (waiting on CI, time, or an event)Queue task is parked (waiting on CI, time, or an event)

    on Oct 29, 2026
11. dezren39 commented on Oct 29, 2026

    

    dezren39

    on Oct 29, 2026

    MemberAuthor

    More actions

    🤖 Agent note · picked up (resume) — verified, re-parked

    • Agent: queue worker (repo-worker-code), Lane A shift
    • Session / ID: queue task 2971
    • Found via: queue claim (resume, stage awaiting_ci)
    • Task: PR id(sync): bound data-phase batches by bytes as well as count (#180) #2215 at head 58745d6d verified fresh:
      • Its one failing check, basic: nix flake check (rustfmt-check), is the pre-existing main breakage (id: pkgs/id/src/meta_client.rs is not rustfmt-clean on main — every PR inherits three failing fmt checks #2151): this PR touches only pkgs/id/src/event_store/sync.rs, while the fmt breakage is in meta_client.rs/tags.rs — exactly PR id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335's files. Not this PR's failure.
      • All other flake-check jobs (incl. test-unit, the gating one per the resume condition) are still pending in the ci: Actions check runs stuck in queued across PRs — no runner pickup since ~05:00Z 2026-10-28 #1599 stall; required basic: proxy port fallbacks passes.
      • Codex: the single review thread (P1, on the old head) was dispositioned by the fix pushed as 58745d6d plus a human reply — I marked it resolved. A Codex review of the current head is still in running state with no findings posted.
    • Expectation: re-parked 20 min. Resume: merge (via merge queue) when test-unit is green, the current-head Codex review shows no undispositioned findings, and only the pre-existing meta_client/tags failures remain — which also requires id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335 to land first for the queue's merge_group rustfmt check.
    • Links: PR id(sync): bound data-phase batches by bytes as well as count (#180) #2215 · fix id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335 · CI stall ci: Actions check runs stuck in queued across PRs — no runner pickup since ~05:00Z 2026-10-28 #1599
12. dezren39

    added

    queue/parkedQueue task is parked (waiting on CI, time, or an event)Queue task is parked (waiting on CI, time, or an event)

    status/parkedDeliberately paused with a recorded resume conditionDeliberately paused with a recorded resume condition

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    and removed

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    status/parkedDeliberately paused with a recorded resume conditionDeliberately paused with a recorded resume condition

    queue/parkedQueue task is parked (waiting on CI, time, or an event)Queue task is parked (waiting on CI, time, or an event)

    work/assignedQueue worker lifecycle stateQueue worker lifecycle state

    on Oct 29, 2026
13. dezren39 commented on Oct 29, 2026

    

    dezren39

    on Oct 29, 2026

    MemberAuthor

    More actions

    agent-note:v1 — worker repo-worker-code (openchamber scheduled lane), task 2971

    Done — PR opened. #2365 bounds the data-phase batch by bytes (8 MiB) as well as count (256), whichever trips first, measured on the wire frame. Bound check extracted as batch_is_full with a new unit test.

    Local: new test pass; full event_store::sync module 16 passed / 0 failed / 2 ignored. Task 2971 completed as pr_opened; merging follows the PR review/CI.
14. dezren39

    added a commit that references this issue on Oct 30, 2026

    Merge pull request #2215 from developing-today/queue/2971-180-sync-ba…

    ...

    6add000
15. dezren39

    closed this as completedin #2215on Oct 30, 2026
16. dezren39

    added a commit that references this issue on Oct 30, 2026

    Merge pull request #2365 from developing-today/queue/2971-180-sync-by…

    ...

    af19d7f