Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Memory and snapshot sync route tests pass when the sender's schema version is dropped

Open Beginner friendly
  • Is something wrong?
#11,996 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, node.js
Domain
backend-api-design, testing

Research direction

Start with server/routes/memory.test.js and server/routes/dataSync.test.js, then compare their cases with the route calls in server/routes/memory.js and server/routes/dataSync.js. Add tests that pass schema version data through to the mocked services and assert how each route handles a 409 or blockedBySchema response. Done when the listed forwarding mutations fail the route tests and the HTTP boundary cases pass.

Written by the indexing model from the issue text.

Description

effort:low model:light plan planner:fable-5-1 test-quality tests

Slice audited: federation route tests (test-quality audit, 2026-10-18).

Problem

Two sync routes forward the sender's version envelope to the service gate that refuses or reshapes cross-version payloads (server/lib/schemaVersions.js). Their route tests never send that envelope, so forwarding is untested.

  1. server/routes/memory.js:88-90 and :101-103 forward schemaVersion to memorySync.getChangesSince / applyRemoteChanges, which gate at server/services/memorySync.js:39 and :107. server/routes/memory.test.js:175, :184, :193 assert getChangesSince('10', 50) and :263 asserts applyRemoteChanges(memories); no case sends ?schemaVersion= or body.schemaVersion. Mutation probe: made both handlers always call the two-argument form.
Test Files  2 passed (2)   Tests  49 passed (49)
  1. server/routes/dataSync.js:186 calls dataSync.applyRemote(category, data, { portosMeta }), the only thing that lets the version gate at server/services/dataSync.js:1362 fire for this route. server/routes/dataSync.test.js:388 ("leaves the write direction alone — apply is gated by its schema-version check, not this") posts no portosMeta and asserts { portosMeta: undefined }, the one value that disables the gate it names. Mutation probe: replaced the forwarded value with the constant { portosMeta: undefined }.
Test Files  1 passed (1)   Tests  42 passed (42)

Impact

syncOrchestrator.js:322 pulls GET /api/memory/sync?…&schemaVersion=N from a peer; the serving install uses that to shape rows and to 409 a newer puller. With forwarding lost, rows go out in the legacy shape with no version in the envelope and the puller applies them as version 0. For the snapshot apply route, a newer-schema snapshot posted to an older install is applied ungated, the corruption schemaVersions.js exists to prevent. The service-level gates are covered only in memorySync.db.test.js, which pregate does not run, so the route layer is the only guard in the default CI plan.

Fix (decided)

  • server/routes/memory.test.js: add GET …?schemaVersion=N asserting getChangesSince received ('10', 50, N), POST with schemaVersion asserting applyRemoteChanges(memories, N), and one case where the mocked service rejects with status 409 and the route passes the status through.
  • server/routes/dataSync.test.js:388: replace the assertion. Post a populated portosMeta: { portosVersion, schemaVersions: { digitalTwin: 99 } }, assert it is forwarded verbatim, and add one case where the mock returns blockedBySchema and the route surfaces it in the response.
  • No production code change.

Scope: small

Acceptance criteria

  • Forcing the two-argument calls in routes/memory.js fails routes/memory.test.js.
  • Forwarding { portosMeta: undefined } unconditionally in routes/dataSync.js fails routes/dataSync.test.js.
  • A 409 or blockedBySchema from the mocked service is asserted at the HTTP boundary in each file.
  • No production code change.
Dominant language
JavaScript
Stars
38
Forks
32
Avg merge
40m
Merged PRs (30d)
996

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from atomantic/PortOS

All issues in atomantic/PortOS

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.