[altruistOS]

Imported Codex sessions can fail to open when their event ordering or stored format differs from the installed DSH runtime. This change writes and validates the runtime’s current format, preserves incremental replies, and retains standard function-call arguments.

Fixes #2.

Changes

• Place the first surface event inside a valid step and migrate from the actual stored format to the installed current format. Adapt persistence reads/writes to the handle-based API and surface read, flush, and close failures.
• Preserve same-turn assistant continuations, replies arriving after a user-only import, and later turns. Unchanged re-imports remain idempotent.
• Repair legacy session copies with paired turn/step regions, current-format restoration validation before writing, and an original .bak backup. Local repair acceptance used temporary copies only.
• Preserve function_call.arguments, including empty strings and object inputs, while retaining legacy input fallback and custom-tool input behavior. Add regression tests.
• Explicitly admit the verified @deepseek-ai/[email protected] peer version. Document official npm/CLI @deepseek-ai/[email protected], session format v4, installation/activation requirements, and text-only reverse-export scope. Desktop application versions are independent.
• Support checksummed session compression on Node 20 through the zstd CLI; newer Node uses the native API. Isolate the MCP test fixture and always dispose its timer.

Validation

Validated head: d17b494f537ba9a12cbed20281900b2b7a175c0d.

• CI run 37308356398: Node 20 and Node 22 each 61 passed, 0 failed, 0 skipped; installation smoke passed.
• CI checks out the exact head, packs it, compares the packed reader, manifest, codec, and compatibility documentation against that source, then installs that same tarball into a scratch profile using official DSH 0.2.0-rc.2 without a version exemption.
• Local isolated DSH acceptance covered import/open of user, assistant, and tool history; same-turn continuation; pending-question replies; new turns; deduplication; and history restoration after restart.
• A native DSH synthetic session exported to an actual Codex JSONL file with the expected roles, workspace, and text. Re-import restored identical text and repeated import added nothing. Previous skip-source/skip-workspace results reflected sample eligibility rules.
• Two legacy-session copies retained matching backups, passed real current-format restoration validation, and opened in DSH. Fixed function arguments were verified in the stored artifact and GUI.

Reverse plugin export preserves user/assistant text, not tool traces or the original thread id; native DSH archive export retains the stored event log. Real Codex Desktop list indexing and full MCP-mirroring acceptance were not tested. No npm publication or production-plugin activation is part of this PR merge.

[Walvez]

Thanks for working on both the step ordering and v3 write issues. The ordering regression tests cover the key converter cases, but I think two items need to be addressed before merging:

1. importCodex catches every error from migrateToCurrent and silently falls back to a v0 header/events. In DSH 0.9.0, persistence.create rejects v0, so a missing migration package or a data-dependent migration failure still breaks import while hiding the useful root cause. Please fail clearly with the migration error instead of attempting the v0 write in this path.
2. The new v3 test returns early when the DSH migration runtime is unavailable, and the stub persistence accepts both formats. This means npm test can pass without exercising the v3 write behavior. Please add a required test path with the real migration packages and verify that the persisted session can be reopened; also cover re-import/appending to an existing session after migration, since diffImportEvents now compares migrated events.

Once these are addressed and the checks run on the updated head, I can review it again. I am leaving the PR unmerged for now.

[altruistOS]

Both review items are addressed, plus a batch of hardening we found while validating against a real DSH 0.10.0 install (current format is now v4).

Review item 1 — no more silent v0 fallback: importCodex no longer catches migrateToCurrent errors; a migration failure now aborts loudly with the session id and the root cause instead of attempting a v0 write.

Review item 2 — required test path with the real packages: the four @deepseek-ai/dsh-session-format-* stage packages are now devDependencies (0.1.7-rc.2, matching the DSH 0.10.0 bundle), so the current-format write path is REQUIRED — no early return. The new write-gate test encodes the written header and every event through the real sessionFormatCatalog (encodeCurrentHeader/encodeCurrentEvent — the exact gate that rejected v3 writes on 0.10.0) and restores the artifact via the real restoreReleasedV4Artifact. Re-import/append after migration is covered on the migrated path (diffImportEvents now compares migrated events). Stub persistence rejects pre-current writes like the real backend, so any v0 fallback becomes a hard test failure. 51/51 tests pass.

Additional hardening from real-machine validation on DSH 0.10.0:

• migrateToCurrent now discovers the vN-to-v{N+1} chain dynamically and starts at the header's ACTUAL stored version — importer v0 artifacts walk the full chain, stored v3 artifacts go straight to v4 (re-running earlier stages failed with "format v0 contains unknown historical event type"). V3→V4 uses the createSessionFormatV3ToV4([]) child-evidence factory (imported sessions are roots). The running DSH app wins resolution, so versions never mix.
• buildDshEvents: a user-kind session/title must carry EMPTY messageSeqs (v4 assertReleasedV4Relationships); the old converter cited the first user message, which the strict restore rejects.
• Paginated continuation rollouts (rollout-<ts>-<uuid>_<fork>.jsonl, same session id, delta-only segments) now merge into ONE candidate per id — each file used to be its own candidate, so the second segment called create again and aborted the whole batch with session … already exists.
• repair-sessions (the migration path for already-imported stores) now scans session.v4.jsonl.zstd, renormalizes turn/step regions (duplicate step markers, orphan surfaces after the last turn/end from old bare-append imports), clears user-title citations, and skips compaction logs with an explicit reason instead of writing invalid artifacts.

Real-store validation: a desktop install upgraded to 0.10.0 with ~105 pre-v4 imported sessions — after the repair every session.v4.jsonl.zstd on disk (146) passes sessionFormatCatalog.createRestore(…, { validation: 'current' }) end-to-end, re-import is idempotent, and a fresh multi-project import converged without errors.

Ready for re-review — happy to adjust if you'd rather split the store-repair parts into a separate PR.

[Walvez]

Thanks for the update. I re-reviewed head a723ab2bdb24a3902cfcfaebdcacbf5fb2e0a544 and installed the locked dependencies with npm ci --ignore-scripts. The original silent-v0 fallback and optional current-format test issues are addressed. All 51 tests pass when invoking the same suites with node --test --test-force-exit (20/20 focused import/order/repair tests also exit normally). Plain npm test did not complete in my environment, so I cannot yet confirm the normal command exits cleanly.

I reproduced the following remaining issues before merging:

1. Same-turn assistant continuation produces an invalid append. Import [user q @1, assistant a @2], then re-import [user q @1, assistant a @2, assistant b @3]. Passing the migrated lists to diffImportEvents produces a suffix starting with turn/start(turn=2) followed by step/end(turn=1, step=1) and step-2 events still referring to turn 1. Restoring old.events + suffix with the real restoreReleasedV4Artifact throws step/end does not match an open turn and step. The existing append test only checks user text, rather than restoring the combined artifact. Please handle this continuation case and add a combined-artifact restore assertion for both same-turn and new-turn updates.

2. Repair can pass encoding and still write an unrestorable artifact. In repairEvents, when a new turn/start arrives while the prior turn/step is still open, the synthetic turn/end is emitted before emitStepEnd. Using a valid migrated two-turn artifact with the first turn's closing step/end and turn/end removed, repairing it and migrating from version 3 makes every encodeCurrentHeader/encodeCurrentEvent call pass, but the real v4 restorer throws turn/end does not match the open turn with no open step. migrateArtifactToCurrent only checks encoding before overwriting the store. Please close the step before the turn, and require complete current-format restoration/relationship validation before writing. A regression test should verify both this damaged-boundary case and the actual store rewrite path.

3. Read errors are treated as empty history. persistence-facade.mjs catches both open('read') and handle.read errors and returns {events: []}. On re-import this can feed diffImportEvents an empty old history and attempt to append the entire source to an existing session. Please propagate the error (the importer already catches inspect errors and skips that session) rather than treating failed reads as successful empty sessions. Add a test asserting no append occurs after a failed read.

4. Durability failures are swallowed. createAndAppend suppresses handle.flush() and handle.close() failures. I injected a flush() error (disk full) and the method still resolved successfully. Please surface persistence failures so the importer cannot report successful import when the durable write failed, while still attempting cleanup. Cover this with failure-injection tests.

These are reproducible gaps beyond the existing 51 passing cases, so I recommend keeping the PR unmerged until they are addressed.

[altruistOS]

All four points are addressed in de5e5b0 (55/55 tests):

1. Same-turn assistant continuation — diffImportEvents now repacks any slice that starts mid-structure into ONE fresh, self-contained turn (turn = oldTurn + 1, steps re-derived from assistant boundaries, seqs continuing the old log), so old.events + suffix is strictly valid no matter which structural boundary the slice starts at. Regression tests assert the COMBINED artifact restores through the real restoreReleasedV4Artifact for both the same-turn and the new-turn update cases.

2. Repair writing unrestorable artifacts — the synthetic turn/end for an implied boundary is now emitted AFTER closing the open step. Additionally, migrateArtifactToCurrent no longer stops at encoding: before touching the store it replays the exact encoded frames through the catalog's own reader with validation: 'current' (createRestore → decodeRow → finish() — full restoration + relationship validation, the same path DSH uses to open sessions) and refuses to write on failure. The damaged-boundary case is covered by a repairEvents regression test.

3. Read errors as empty history — persistence-facade's inspect() now propagates open/read failures instead of returning {events: []}; the importer's existing catch skips the session. Test asserts NO append occurs after a failed read.

4. Swallowed durability failures — createAndAppend and append now surface flush/close errors after attempting cleanup (append error still wins; flush error beats close error). Failure-injection test: a disk full flush rejects the import and cleanup (append → flush → close) is observed before the error surfaces.

Happy to iterate if anything else comes up.

[Walvez]

Re-reviewed de5e5b05d85aea4ef4698851f1be7a845144ac28:

• Plain npm test now exits normally here: 55 passed, 0 failed, 0 skipped, no force-exit flag needed. The previous non-exit observation did not recur.
• All four previous reproductions are addressed: same-turn continuation restores, damaged-boundary repair restores, failed reads propagate, and failed flushes reject the write.
• I also exercised the actual disk rewrite in a temporary store: encoded a damaged v3 artifact with the real v3 codec, ran migrateArtifactToCurrent(..., {write:true}), and reopened the written v4 file through sessionFormatCatalog.createRestore(..., {validation:'current'}). This passed and the original .bak was retained.

There is one remaining continuation edge case in diffImportEvents:

First import while a reply is still pending: import a rollout containing only [user q @1]; then append [assistant a @2] to that same rollout and re-import. I reproduced this through importCodex itself with a temporary Codex home. The second import reports updated 0, skipped 1, and the stored assistant count remains 0. Calling diffImportEvents on the migrated user-only and user+assistant artifacts likewise returns [].

The equal-user-count branch initializes cut = nextEvents.length; when oldAssistants === 0, the matching condition is never reached because the counter is incremented before being compared. Please handle the transition from zero stored assistants to the first assistant, preserve the new content without duplicating the user, and add a regression that checks the stored answer, combined-artifact restoration, and idempotence on the next unchanged import.

This is a content-loss case in the existing continuation logic, so I recommend resolving it before merging. Apart from this remaining case, the previous four review findings are closed.

[altruistOS]

Fixed in 33f1964 (58/58 tests):

Root cause — diffImportEvents's equal-user-count branch incremented its assistant counter before comparing it with oldAssistants, so whenever the stored history's last turn had no assistant yet (oldAssistants === 0), the cut position could never match and the entire continuation was dropped (updated 0, skipped 1, answer lost). The same defect had two more shapes from the same family: a pending last turn after earlier complete turns ([q1,a1,q2] → [q1,a1,q2,a2] dropped a2 because the seen === match - 1 guard also failed), and the new-user branch dropping a pending turn's reply when a further user followed.

Fix — rollouts are append-only, so old's users and assistants are prefixes of next's. The first new content is now the earlier of the (oldAssistants)-th assistant (0-based — so the zero case correctly treats the first assistant as new) and the (match)-th user. A slice that continues old's last turn is repacked into one fresh turn (wrapAsFreshTurn, as for the same-turn case); complete new turns keep their converted structure and are renumbered after it, so a pending reply and a following new user are both stored.

Regression tests (all through importCodex with a temporary Codex home):

• pending-question continuation: the stored answer is present, the combined artifact restores through the real restoreReleasedV4Artifact, the user is not duplicated, and the next unchanged import reports updated 0, skipped 1 (idempotent);
• pending reply and a following new turn: both stored, combined restore passes;
• pending last turn after earlier complete turns: stored + combined restore + idempotence.

npm test: 58 passed, 0 failed, 0 skipped, exits cleanly.

Ready for re-review.

[Walvez]

Re-review of 33f196485c0efc298cac3be9dd401f16bd66aa46 is complete.

• Ran plain npm test: 58 passed, 0 failed, 0 skipped, normal exit, no force-exit flag.
• Independently repeated the original pending-question reproduction through importCodex with a temporary Codex home. The second import now reports updated 1; the answer is retained, the user is not duplicated, and the combined artifact passes the real v4 restorer.
• A third unchanged import reports updated 0, skipped 1 and leaves the stored event count unchanged.
• The added tests also cover a pending last turn after earlier completed turns and a pending reply followed by a new user turn. The previous review findings remain covered by the passing suite.

I have no remaining blocking findings in the code paths reviewed. From the code review and automated testing perspective, this is suitable for merge. GitHub's latest CI run is still action_required, so please allow the workflow to run and confirm its result before merging. I have not run a live desktop DSH test; the real codec/restorer checks here are automated compatibility checks, not a desktop acceptance test.

One documentation follow-up: please update the PR description to match the final implementation (dynamic current-format/v4 support, no v0 fallback, 58 tests, and the expanded repair/API-adapter scope). The current description still describes the earlier v3/fallback/45-test implementation.

Thanks for addressing the reproducible cases.

[altruistOS]

Thanks for the re-review. The PR description is now rewritten to match the final implementation (dynamic current-format discovery from the stored version, no v0 fallback, handle-based API adaptation, repair scope, 58 tests) — the old text described the earlier v3-era state.

On the two open checklist items: the CI action_required gate is on your side (first-contribution workflow approval), and the live desktop acceptance was done on my end — a real desktop 0.10.0 install with ~105 pre-v4 imported sessions was repaired (146/146 artifacts pass createRestore(validation:'current')), and cross-project imports were verified in the running app. Ready to merge whenever the CI run is green.

[altruistOS]

Small pointer on the CI gate: the action_required workflow runs can only be approved from the maintainer side — fork contributors have no approval button (see Approving workflow runs from forks). On your side it's: PR → Files changed → top-right Awaiting approval button → Approve workflows to run in the merge-status panel. No .github/workflows/ changes are in this PR's diff, so the run should be safe to approve.

[Walvez]

Thanks for clarifying the maintainer-only CI approval and your DSH 0.10.0 desktop validation.

We now have a separate local acceptance result on the maintainer's currently installed runtime, which changes deployment readiness for that environment:

• Runtime: DSH 0.1.1-rc.2, actual SESSION_FORMAT_VERSION = 0, legacy npm/CLI web-profile installation.
• Tested the same head 33f196485c0efc298cac3be9dd401f16bd66aa46 as an installed production tarball in an isolated web profile with synthetic rollouts.
• Six import attempts fail with cannot resolve @deepseek-ai/dsh-session-format-* migration packages. This runtime contains no migration chain, and the tarball does not install the devDependencies.
• Baseline control: the currently installed 1.6.1 plugin (matching the PR base import/converter implementation), on the SAME runtime and SAME synthetic source, imports successfully and the GUI opens the user, assistant, tool call and result.
• Repair on a copied temporary old-session sample fails because the session-format catalog is unavailable. No real store was modified.
• With a clean PATH the local automated suite is 58/58; the default PATH has two unrelated React/React DOM SSR resolution failures. Existing plugin/configuration file hashes are unchanged and the isolated services have been stopped.

This does not contradict your 0.10.0 validation: it identifies a legacy-v0 compatibility regression on the runtime the maintainer actually uses. My earlier code-review clearance applies to the migration-equipped/current-format scenarios tested, not to this legacy runtime.

Please clarify the minimum supported DSH version. If legacy v0 remains supported, select the v0 write path based on positively identifying the host's supported format; do NOT reintroduce the blanket catch-and-v0 fallback on migration errors for newer hosts. If the PR intentionally drops that runtime, please document/enforce the minimum version with a clear actionable error and an upgrade path rather than failing at package resolution. We can then choose whether to upgrade the maintainer's runtime or preserve backward compatibility before deployment/merge acceptance.

For now, local acceptance is not complete, so please keep the PR unmerged while this compatibility decision is resolved.