Keep memory sync conflict clocks monotonic at wire precision
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, postgresql
Research direction
Read update_memory_timestamp() in server/scripts/init-db.sql and inspect how the memory schema is provisioned on upgrades; compare the catalog clock implementation in #12500. Then review server/services/memorySync.js and the tests in server/services/memorySync.db.test.js, using server/services/catalogSync.changeClock.db.test.js as a pattern. Done means the three clock regressions pass, access-stat-only updates create no feed work, and existing installs receive the trigger update.
Written by the indexing model from the issue text.
Description
Problem
Memory federation has the same LWW clock defect #12500 fixed for the catalog. update_memory_timestamp() in server/scripts/init-db.sql stamps a locally changed memory with transaction-start NOW() when NEW.updated_at IS NULL OR NEW.updated_at = OLD.updated_at. server/services/memorySync.js exports updated_at through Date#toISOString() (millisecond precision) and applies peer rows only WHERE EXCLUDED.updated_at > memories.updated_at.
Consequences, by the same mechanism as #12500:
- A transaction that began before a concurrent, already-committed memory edit stamps an OLDER clock than the row it overwrites; peers that already applied the earlier version reject the newer one and the feed cursor moves past it.
- Two local changes within one wire millisecond (or within one transaction) ship equal clocks, so the second is skipped by peers.
- A local edit after a future (clock-skewed) peer clock moves the clock backward.
Decided fix
Reuse the #12500 invariant: stamp GREATEST(date_trunc('milliseconds', clock_timestamp()), date_trunc('milliseconds', OLD.updated_at) + INTERVAL '1 millisecond'). Either call the shared catalog_next_change_clock() (consider renaming to a domain-neutral name in a compatible way) or add a memory-owned equivalent next to update_memory_timestamp() in init-db.sql and wherever the memory schema is provisioned on upgrade (memories are provisioned outside ensureSchema, see SQL_ONLY_TOLERATED in server/lib/db.ddlParity.test.js). Preserve explicit peer clocks, the access-stat no-op path, and the strict > comparison.
Acceptance criteria
- Overlapping-transaction, same-transaction and future-clock regressions in
server/services/memorySync.db.test.js(pattern:server/services/catalogSync.changeClock.db.test.js), failing before the fix. - Access-stat-only updates still produce no feed work.
- Existing installs receive the new trigger body through the established memory schema path.
Found while fixing #12500. model:heavy for distributed clock semantics; effort:medium because the catalog fix is a worked template.
- Dominant language
- JavaScript
- Stars
- 38
- Forks
- 32
- Avg merge
- 34m
- Merged PRs (30d)
- 993
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from atomantic/PortOS
-
effort:medium enhancement model:medium plan
Difficulty 4/5 1-2 days Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
bug effort:high model:heavy plan
Difficulty 4/5 3-5 days Newbie friendliness 43/100
atomantic/PortOS#12748 · 1 comment ·
Maintainers usually reply within 1 day
-
Reconcile dead-owner settlement reservations left by crashed publicationsPossibly taken @atomantic claimed this today. Openbug effort:high in-progress model:medium plan
atomantic/PortOS#12740 · 1 assignee ·
Maintainers usually reply within 1 day
-
CI planner runs the full suite for requirements-only Python pin changesPossibly taken @atomantic claimed this today. Opencode-quality effort:low in-progress model:medium plan
atomantic/PortOS#12739 · 1 assignee ·
Maintainers usually reply within 1 day
-
Worktrees made outside the claim prompt never get dependency links, and a cache-only node_modules blocks a later linkPossibly taken @atomantic claimed this today. Openbug effort:medium in-progress model:medium plan
atomantic/PortOS#12734 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in atomantic/PortOS
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
fix(套件): test_bundle 往仓库的 preset/skills 写哨兵，并发跑的 test_installer 拷贝时撞 ENOENT（CI 红）Possibly taken @Miaotofu01 claimed this today. Openneeds-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Miaotofu01/Study-Mate#216 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
beginner-friendly category:fixtures community enhancement first-timers-only good first issue hacktoberfest help wanted low hanging fruit micro-contribution type: task up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Berserk-hub150/skillhawk#229 · 1 comment ·
Maintainers usually reply within 8 days