More efficient manifests #10
Labels
No labels
agent
blocked
agent
new
agent
review
agent
working
complexity
high
complexity
low
priority
high
priority
low
priority
medium
risk
high
risk
low
risk
medium
type
bug
type
chore
type
feature
type
security
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tfks/dropbear#10
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
At only a few entries, the manifest for each device is ~1KB. At only one thousand files, those manifests are ~1MB. dropbear should not update its manifest if there are no changes. Currently, it does that on every sync regardless.
While still early, we should consider alternate manifest file formats and/or compression.
Treat this as an investigation for now. No spec yet since we don't know which direction to go yet.
Brief — Developer
Phase: simple. Run
fjx dev prompt simplefor the cycle protocol.Ledger for: agent-pm
Status: watching @ 2026-06-27T00:06:23.998Z
Briefs:
Activity
(none)
(PM manages this ledger; agent section unused)
Ledger for: agent-dev
Status: blocked @ 2026-06-27T00:14:38.192Z
Finding: not a simple change — recommend re-route to
investigateI read the issue as having two parts and investigated both against the current code.
Part 1 — "don't update the manifest if there are no changes" — already implemented
internal/upload/run.goalready short-circuits the manifest republish when the tick has no work.runState.isNoOp()(run.go:147) returns true when there are zero uploads, downloads, already-present paths, deleted rows, applied tombstones, and reconciles.runUploadBlobsreturns theerrNoUploadWorksentinel in that case (run.go:309-311), andRunreturns early on that sentinel (run.go:184-190) beforerunBuildAndPutManifest(run.go:194) ever runs. So in true steady state the manifest is not re-PUT.git log -L :isNoOp:internal/upload/run.goshows this guard has existed since the sync subcommand was first implemented (0dbd501), so the issue's premise ("it does that on every sync regardless") does not match the current code for the no-op case.Part 2 — the genuinely open design questions (the author's stated "investigation")
The issue body explicitly says: "Treat this as an investigation for now. No spec yet since we don't know which direction to go yet." The remaining asks are real but design-level, not a one-line fix:
isNoOp()is false (so the manifest is rebuilt and PUT) in cases where the manifest's content can still be byte-identical to what's stored — e.g. an applied-tombstone watermark advance, a reconcile, or an already-present download. Suppressing the PUT there requires detecting "content unchanged." That is non-trivial because the canonical manifest embedsCreatedAt: now(internal/upload/manifest.go:50, included in the sha256 over canonical bytes), so naive hash equality never holds. Options are (a) fetch the prior manifest and compare entries+applied-tombstones — but that downloads the ~1MB object the issue wants to stop moving, which is counterproductive, or (b) persist a content-hash (excludingCreatedAt) in local state and compare. (b) is a new abstraction / schema decision.This is not a simple one-line fix and should be re-routed to
investigate(orpropose) per the simple-phase contract. No code was changed this cycle.Blocker: no handoff path for a no-code re-route
I cannot complete the prescribed handoff. The simple-phase escape hatch ("if the change isn't actually simple… stop and report it in the ledger rather than expanding scope — PM will re-route to
proposeorinvestigate") produces no code and therefore no PR, but the handoff command requires one.Four checks:
fjx dev done --help: "Mark an issue's work ready for review: transition the issue to agent/review, assign the issue to agent-pm for routing, and assign the linked PR to $FJX_OWNER." No flag to hand off without a PR.fjx dev --helpconfirms the only other transitions arerelease(crash-recovery: adds agent/blocked, reassigns to $FJX_OWNER, appends a "crashed" entry — semantically wrong for a clean finding) andledger.fjx dev done 10:No open PR links to issue #10 (looked forCloses #10/Fixes/Resolves/Refsin open PR bodies). Open the PR with one of those keywords in the body before runningfjx dev done.—rg -i 'no open PR|without a PR|no-code|re-route' wiki/returns nothing; no prior occurrence in the ledger.simpleprompt step — it directs me to "stop and report it in the ledger rather than expanding scope — PM will re-route," i.e. report-only, no PR. That conflicts withfjx dev done's PR gate.Smallest unblock: either a
fjx dev donemode that hands a no-code finding back to agent-pm without an open PR, or PM re-routes #10 toinvestigate/proposedirectly from this ledger. I have not changed labels/assignment beyond applyingagent/blocked, to avoid routing around fjx.