Skip to content
edgesync Timeline
Login

Timeline

Parents and children of check-in [fabb4e3453]

2026-05-13
20:27
refactor(hub): register modernc SQL driver internally (#166)

The hub package promised consumers wouldn't need to import libfossil directly, but they still had to blank-import libfossil's SQL driver to satisfy the underlying db layer's registration requirement. Move the blank import into hub itself (hub/driver.go) so the package fulfills its own dependency.

Consumers like sesh can now reduce their main.go to a plain `import "github.com/danmestas/EdgeSync/hub"` (or whatever wrapper they use) without taking a direct dep on libfossil's internal SQL machinery.

modernc is registered as the production default. If a consumer ever needs ncruces (WASM/WASI), an escape hatch can be added then.

Tests in hub/ drop their now-redundant blank imports.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> check-in: 754914fd82 user: [email protected] tags: trunk, v0.0.18

00:13
refactor(agent): drop mergeWithParent now that libfossil v0.6.2 ships the fix (#165)

libfossil#30 / EdgeSync#163 shipped consumer-side and upstream respectively. With libfossil v0.6.2 (PR #32, commit e6d34fb), Repo.Commit merges parent F-cards with supplied Files internally when ParentID > 0 — the exact behavior agent.mergeWithParent was emulating. Drop the duplicate.

Repo policy (CLAUDE.md "Upstream-fix policy") is unambiguous: when a fix lands in a repo we own, the workaround in the consuming repo should be removed, not left as defense-in-depth. libfossil is ours; a regression there gets fixed there.

Bumps: - root go.mod: v0.6.1 → v0.6.2 - leaf/go.mod: v0.5.0 → v0.6.2 (was lagging; auto-bump workflow has been failing per #146/#158) - bridge/go.mod: v0.5.0 → v0.6.2 (same)

Keeps the regression tests TestAgent_Commit_PreservesParentFiles and TestAgent_Commit_SuppliedFileOverridesParent — they assert behavior, not implementation, and now serve as integration coverage so any future libfossil regression on full-tree manifest emission surfaces in EdgeSync CI too.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> check-in: fabb4e3453 user: [email protected] tags: trunk

2026-05-12
23:50
feat(hub): persist .commit publish watermark across hub restarts (#164)

publishedRID was in-memory only. initPublishWatermark snapshotted the current max ci rid on every start, so any commit that landed in the repo but didn't get its .commit notification out before the hub died (crash mid-publish, HTTP push that completed the SQLite write but crashed before the wrapper ran publishNewCommits, or an offline tool writing to the repo while the hub was down) became silently un-propagated. Peers caught up incidentally on the next commit or not at all. Real gap.

Persist the watermark to the repo's config table under "edgesync:hub-published-rid" after each successful publish. On startup, initPublishWatermark reads the persisted value first and falls back to the max-rid snapshot only when nothing is persisted (cold start). Schedule a one-shot publishNewCommits call publishCatchupDelay (3s) after NewHub so it runs after NATS leaf clients have had time to reconnect on the same leaf port — an immediate catchup fires into a void because nats-core has no per-subscriber queuing.

Stop cancels the pending catchup via catchupStop so the goroutine doesn't outlive the hub.

Regression test TestCrossLeaf_HubRestart_RepublishesUnannouncedCommits: two hubs leaf-linked on a stable leaf port; stop A, open the repo file directly via libfossil and commit (no hub, no NATS, no publish hook), restart A; assert B reads the offline file via the delayed startup catchup. The "open repo file directly" trick is morally equivalent to "hub crashed after libfossil's write but before the wrapper's publish" — both produce a commit that's in the repo but unannounced.

Known limitations (deferred): - If no peer reconnects within publishCatchupDelay, the catchup publish is still lost. JetStream-durable .commit subject would close the gap; tracked as a follow-up. - The .commit subscriber on the pull side doesn't advance the receiving hub's watermark, so a pulled-in commit will be republished on the receiver's next restart. Idempotent on the far side (the subscriber's pull converges to zero blobs) but wasteful chatter; can be tightened in a follow-up. - v1→v2 upgrade with un-announced backlog at the time of upgrade treats those commits as "already known" — same silent-loss behavior as v1; not made worse.

Refs #161 review notes.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> check-in: 00bc87892b user: [email protected] tags: trunk