Follow up items for the week of July 4, 2026

[espg]

🤖 from Claude

Sweep of closed PRs from the last 10 days (June 24 – July 4, 2026): #44, #70, #103, #105, #106, #107, #111, #112, #113, #115, #123, #124, #125, #127, #128, #129, #131, #134, #136, #140, #144, #146, #147, #150, #152, #153, #159, #162. PRs #103/#105/#106/#107 were already surfaced by the prior sweep (#114); this issue covers new gaps from the remaining 24 PRs, plus a re-verification of #114's 4 carry-forward items against current main. Two of #114's items are now resolved and excluded: the cryocloud notebook now explicitly documents itself as non-Binder-runnable rather than silently requiring credentials, and jupyterhub_example.ipynb no longer has hardcoded deployment-specific ARNs. Two carry-forwards are still open and folded into the list below.

Items

(1) Zero-photon granule segment-read cost still unaddressed in the production read path — carry-forward from #114 — PR #96 / touched by #152

No July PR added a general per-granule early exit for granules that don't actually cross the shard. PR #152 built an experimental "a-priori read plan" (arm 2a) that can skip the geolocation-rate read using pre-extracted chunk-boundary geometry, but it's wired only into the 88S stress-benchmark config (issue #148, still open) — the default _planned_read_group path (src/zagg/processing/read.py) still reads every granule's full coarse-level segment-coordinate + link arrays before it can tell the granule doesn't intersect.

(2) publish_mirror.sh --creds still ignores region/endpoint fields — carry-forward from #114 — PR #85

Current deployment/aws/publish_mirror.sh only pulls AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN out of the --creds JSON; region/endpoint still come only from MIRROR_REGION. Unchanged by any PR in this window.

(3) shard_order write-path knob (PR #134 Phase 8) has no tracking issue — PR #134

PR #134's own checklist left Phase 8 unstarted: "decouple the sharding object from the dispatch shard... a shard_order knob (parent_order < shard_order <= chunk_inner)... makes large/dense shards (88S) writable under the 2 GB cap." This is the specific mechanism needed to fit dense o8/o9 shards — exactly the 88S stress target being actively pursued in #148 — under the Lambda memory cap. Issues #138 and #142 mention shard_order only in passing, and #133 (the issue they point back to) is already closed. No issue actually tracks implementing this knob.

(4) Local-backend ragged-write fan-out has no cross-worker concurrency cap — PR #147

_write_ragged_fanout (src/zagg/processing/write.py) bounds each worker's inner CSR-write pool at _RAGGED_WRITE_CONCURRENCY = 128 — safe on Lambda (one worker per isolated container) but on the local backend the theoretical peak is outer_cells × 128 threads, since fd_safe_max_workers() only floors the per-call bound, not a cross-pool budget. Flagged as an explicit open "Question for review" in PR #147 with no reply in the thread; the flat constant is unchanged.

(5) Sync Lambda-dispatch fallback still has no TCP keepalive, leaving it exposed to the same idle-kill #151 was opened to fix — PR #153, Refs #151

The root-cause analysis on #151 proposed a short-term Config(tcp_keepalive=True, ...) fix for the ~4-minute SNAT idle-connection kill; espg went straight to the durable async/poll fix (#153) instead. PR #153's own self-review flagged that keepalive "is now only relevant to the sync fallback path" and needs either a two-line addition or an explicit won't-do note on #151 — neither happened, and #151 was closed by #153's merge with no further comment. Confirmed in current src/zagg/runner.py: both boto_config = Config(...) blocks (read_timeout=960 and read_timeout=900) omit tcp_keepalive. The sync path is the documented fallback for oversized async payloads and pre-#153 workers — exactly the scenario #151 hit.

(6) Run-level retry budget still missing (per-cell retries have no overall circuit breaker) — PR #127, echoes #119

PR #127 fixed per-cell retry behavior (_invoke_lambda_cell in src/zagg/runner.py) but explicitly left standing: "the run-level retry budget... is explicitly out of scope here; the per-cell dispatch/LAMBDA_RETRY path in dispatch.py is untouched." The same gap was flagged in #119 (closed) but never turned into its own issue — a systemic failure (e.g. AWS throttling across a whole run) still has no circuit breaker; every cell retries independently.

(7) CSR-write consolidation ("option 2") has no successor tracking issue — PR #147, Refs #142

#142 discussed consolidating the K per-inner-chunk CSR groups into one group per dispatch shard (~1500 S3 objects → ~6, cheaper consolidate_metadata), requiring re-offsetting cell_ids into shard-wide space and generalizing the reader's hardcoded _CHUNK_SIDE=64/divmod assumption in src/zagg/readers/tdigest_tensor.py. #142 is now closed, satisfied only by option 1 (the per-cell writes just merged); option 2 has no home.

(8) Upstream h5coro hyperslice hardening left as an untracked one-liner — PR #162

PR #162's fix note: the optional upstream setdefault("hyperslice", []) hardening "is out of scope here per the issue — it stays a candidate one-liner for a future SlideRuleEarth/h5coro PR." Distinct from #154 (numpy-vectorization hand-off); nothing else tracks this specific defensive nicety.

(9) Browser verification of the ipyleaflet shardmap viewer still deferred — PR #44

PR #44's "Questions for review": "Browser verification of the live ipyleaflet map is still deferred (constructs + layers attach headlessly; in-browser rendering can't be verified here)." #74 (globe-view viewer, Phase B) is a separate, larger feature and doesn't cover manually verifying the existing inline widget (src/zagg/viz/leaflet.py) in a real browser.

(10) Two self-acknowledged non-blocking nits in the benchmark runner — PR #146

From PR #146's self-review: (a) a target manifest exceeding the 16-way concurrency cap lets already-queued targets finish before an abort rather than stopping immediately; (b) per-target progress lines print only after all targets complete rather than streaming. File: .github/scripts/run_benchmark.py. Both called non-blocking by the author; neither has a tracking issue.

---

Priority / severity table

Priority	Item	Severity	Source PR
1	Zero-photon granule read cost — wasted full segment I/O scales with AOI size, still only fixed experimentally for one benchmark config	High	#96 (carry-forward)
2	shard_order write-path knob untracked — blocks the active 88S dense-shard-under-2GB effort	Medium-High	#134
3	Local-backend ragged-write fan-out has no cross-worker cap — FD/resource-exhaustion risk at scale	Medium	#147
4	Sync Lambda-dispatch fallback missing TCP keepalive — same idle-kill failure mode #151 was opened for	Medium	#153
5	Run-level retry budget missing — no circuit breaker for systemic (not per-cell) failures	Low-Medium	#127
6	CSR-write consolidation "option 2" — object-count/efficiency gap, no correctness impact	Low-Medium	#147
7	publish_mirror.sh --creds ignores region/endpoint — potential mis-upload to wrong region	Low	#85 (carry-forward)
8	ipyleaflet shardmap viewer browser verification still deferred	Low	#44
9	Upstream h5coro hyperslice hardening — untracked one-liner for a library not owned here	Low	#162
10	Benchmark runner abort/progress-streaming nits — cosmetic, author-acknowledged	Low	#146

[espg]

🤖 from Claude

Triage of the 10 items against current main (2026-07-07) and the issues filed since this sweep (#174, #177, #179, #180). Recommendation per item, grouped by the priority table. Net result: 5 promotes ((1) and (6) as discuss; (2), (4), (5) as small-fix), 2 folds into existing threads ((7) into #122, (8) into #154), 2 drops ((9), (10)), and 1 already done on main ((3)).

High

(1) Zero-photon granule read cost — promote to its own issue, label discuss. Still real: the default planned route (_planned_read_group, src/zagg/processing/read.py:294) reads every granule's full coarse segment coords + link arrays before it can tell the granule misses the shard; the a-priori arm that skips them (_apriori_read_group, dispatched at read.py:644) is gated on read_plan.chunk_boundaries, i.e. the #148 benchmark arm only. The two new read-wall issues are adjacent but do not cover it — #179 makes selection reads compiled/pooled and #180 overlaps granules; both make the wasted reads cheaper or hidden, neither eliminates them. Genuine design fork:

• (a) Productionize the a-priori chunk-boundary plan (generalize the add 88 south stress test shard + benchmark #148 arm 2a): biggest win (no selection read at all for non-crossing granules), but requires the per-granule boundary parquet as a standing catalog artifact, not just a benchmark fixture.
• (b) Cheap early exit inside the planned path: test shard intersection from the coarse coordinates alone before reading link arrays — smaller win, no new artifacts, purely local change to read.py.
• (c) Prune at dispatch: filter each shard's granule list from the shardmap's granule-shard pair table so workers never receive non-crossing granules — zero worker-side cost, but moves correctness onto shardmap freshness.

Sequencing note: any of these collides textually with #179/#180 in the read path — worth ordering explicitly against them.

Medium-High

(3) shard_order write-path knob — already covered; no new issue needed. It is implemented on main: commit 7886243 ("phase 8 of issue #133", landed with PR #134's merge on 2026-06-30) added get_shard_order (src/zagg/config.py:1435), threading via src/zagg/grids/__init__.py:57, range + sharded validation in src/zagg/grids/healpix.py:144-161, the object-split write path in src/zagg/processing/write.py, and tests in tests/test_processing.py. (PR #134's body still shows Phase 8 unchecked — the commit landed at merge time; noting for archaeology.) The remaining work — actually exercising shard_order on the dense 88S shard under the 2 GB cap — is exactly #148's scope, which is open (implement + waiting).

Medium

(4) Local-backend ragged-write fan-out cap — promote, label small-fix. Unchanged: _RAGGED_WRITE_CONCURRENCY = 128 (src/zagg/processing/write.py:31) and the bound at write.py:415 (min(_RAGGED_WRITE_CONCURRENCY, len(ragged_writes), fd_safe_max_workers())) is per-call only, so the local-backend peak is still outer_cells × 128 threads. Two candidate fixes, either one small:

• (a) Divide the budget: local backend passes a per-worker cap of _RAGGED_WRITE_CONCURRENCY // n_outer_workers — static and trivial; slightly under-uses when only a few cells are ragged-heavy.
• (b) One process-wide semaphore capping total in-flight CSR writes across pools — exact bound, a bit more plumbing.

Lambda path stays as-is either way (one worker per container; 128 is safe there).

(5) TCP keepalive on the sync dispatch fallback — promote, label small-fix. Confirmed still missing: both Config(...) blocks in src/zagg/runner.py (lines 676–681 and 1331–1336) omit tcp_keepalive=True. Two-line change plus the closing note on #151 that PR #153's self-review already proposed.

Low-Medium

(6) Run-level retry budget — promote, label discuss (semantics need a decision before code): the per-cell RetryPolicy / LAMBDA_RETRY machinery in src/zagg/dispatch.py still has no run-level circuit breaker. Open questions for the thread: does the breaker trip on a total-retry budget per run or a failure-rate trip wire, and does it also cover the #153 async/poll path or only the classic dispatch loop.

(7) CSR-write consolidation "option 2" — fold into #122 rather than a new issue. #122 is already the sharded-write follow-up thread (discuss + waiting), and the blocking assumption is unchanged — hardcoded _CHUNK_SIDE = 64 / divmod in src/zagg/readers/tdigest_tensor.py:57 and :335. A standalone discuss issue also works if you prefer one-topic threads.

Low

(2) publish_mirror.sh --creds ignores region/endpoint — promote, label small-fix, and the issue must name the file (deployment/aws convention — same pattern #174 uses for stand_up.sh): the script still extracts only the three key fields from the --creds JSON (deployment/aws/publish_mirror.sh:65-78) and takes region solely from MIRROR_REGION (line 35).

(8) h5coro hyperslice hardening one-liner — fold into #154, no new issue. #154 (discuss + waiting) is already the parking lot for upstream h5coro hand-offs; a one-line bullet there beats a standalone issue for a library not owned here. Context has also moved: main now pins h5coro>=1.0.5 plus h5coro-hidefix>=0.3.0 (pyproject.toml:30,37), so the one-liner should be re-checked against whichever upstream actually receives it.

(9) ipyleaflet browser verification — drop as tracked work. It is a one-time human-in-a-browser check of the existing widget (src/zagg/viz/leaflet.py), not agent-executable, and #74 (globe-view Phase B) intentionally does not cover it. Suggest a two-minute manual look next time a JupyterHub session is open; an issue would just go stale.

(10) Benchmark-runner nits — drop. Both are still present (fut.result() inside as_completed at .github/scripts/run_benchmark.py:281-282 lets queued targets finish before an abort propagates; per-target lines print only after collection, lines 283–290), and both remain cosmetic and author-acknowledged. Not worth a tracking issue.

Questions (one pass)

1. Item (1): which arm — (a) productionize the a-priori plan, (b) cheap in-path early exit, or (c) dispatch-time pruning from the shardmap? If undecided, the issue opens as discuss carrying all three options.
2. Items (2), (4), (5): OK to open all three as small-fix issues on the next sweep (bundleable into one claude/small-fixes-<date> PR), with (2)'s issue naming publish_mirror.sh explicitly to authorize the deployment/aws edit?
3. Items (7), (8): fold as comments into Sharded followup #122 and Hand-off: upstream numpy-vectorized shuffleChunk to h5coro #154 respectively, or standalone issues?

---

Generated by Claude Code