DeepSeek Harness 0.1.2 alpha.3 removes SQLite session persistence: export before you upgrade

Author: Ahab · Date: September 1, 2026

Quick answer

DeepSeek Harness 0.1.2-alpha.3, published on August 31, removes the optional @deepseek-ai/dsh-session-persistence-sqlite provider. The release does not delete an existing database, but the new build does not open or migrate that database either. If your composition selected the removed provider, keep a verified 0.1.2-alpha.2 environment, quiesce the writer, export each logical Session, and prove a JSONL restore before switching versions.

This is a pre-release compatibility cut, not a stable GA migration. At the checked source snapshots, alpha.2 resolves to commit 0a53fb55bea101816fa226bb964ae2bed71c343b and alpha.3 to dd6322d604e00eec1ba5e0c8541159906a21094a. npm exposes alpha.3 through the alpha tag while latest still points to 0.1.1-rc.2. Pin the exact artifact you test.

Who this is for

This checklist is for operators who explicitly added the SQLite Session persistence package to a custom DeepSeek Harness composition. Shipped profiles did not enable it by default. If you use the ordinary JSONL Session store, this removal does not require a store migration—but you should still verify your resolved plugin graph before upgrading.

For the wider event-log, compaction, and crash-replay model, read the DeepSeek Harness session reliability guide. For transport recovery, use the alpha.2 reconnect runbook.

First identify which SQLite you actually use

The word “SQLite” now names three different roles. Only one was removed.

Package or file	Role	Alpha.3 status	Migration meaning
`@deepseek-ai/dsh-session-persistence-sqlite`	Authoritative durable Session events in one database	Removed	Export logical Sessions with an older build before upgrading
`@deepseek-ai/dsh-session-query-sqlite`	Rebuildable FTS5 search index over persistence	Still present	Do not treat this derived index as the Session source of truth
`@deepseek-ai/dsh-storage-sqlite`	Generic domain key-value storage	Still present	Inventory separately; it is not the Session log
`@deepseek-ai/dsh-session-persistence-jsonl`	One authoritative compressed JSONL artifact per Session	Sole first-party Session provider	Target for a first-party migration

Search the effective composition, generated config, lockfile, and runtime diagnostics—not just a source template. A dependency in node_modules is not proof that the provider is active. The decisive evidence is a mounted plugin row named @deepseek-ai/dsh-session-persistence-sqlite and its resolved database path.

Why copying the database is not enough

An immutable copy of the SQLite database is rollback evidence, not an alpha.3 import. The current source removes the provider package, schema resources, configuration surface, and backend-specific tests. It deliberately ships no read-only importer.

The old provider also exposed no per-Session raw artifact. Its own documentation described a logical migration through the shared persistence API: enumerate Sessions, load each header and ordered event stream from the source, then create and append them through the destination provider in a separate process. One composition owns one ctx.sessionPersistence provider, so source and destination should not be mounted as two competing authorities in the same process.

Do not assume the Web /export command repairs this gap. The current Session-log ZIP export requires the JSONL provider's raw per-Session artifact. It is a browser download path, not a generic Host-side SQLite conversion tool.

A seven-stage migration workflow

1. Record the exact boundary

Capture the running binary version, lockfile digest, alpha.2 commit, Node version, configuration layers, resolved SQLite path, journal mode, DSH_HOME, workspace root, and Session count. Confirm the package with a read-only registry check:

npm view @deepseek-ai/dsh@0.1.2-alpha.2 version dist.integrity --json

Do not replace the working installation until the export is independently readable.

2. Freeze writes and take a consistent snapshot

Stop new prompts, scheduled work, subagents, and background jobs. Wait for every active turn to reach a terminal state and flush persistence. Then take a database-consistent backup. If WAL mode is active, use SQLite's backup mechanism or copy the database with its live journal state only after the writer is fully stopped; copying one file from a live three-file set is not a consistency guarantee.

Hash the snapshot and keep it read-only. Record attachments and external spill artifacts separately because a Session event may preserve a locator without copying its target.

3. Reopen with the old provider

Use a disposable environment pinned to alpha.2 and the original provider configuration. Point it at a copy of the snapshot, never the only original. Refuse the run if the old build reports an ownership, schema, path, or permissions mismatch. Do not edit the database with ad hoc SQL to force it open.

4. Export logical Sessions

The old provider's supported seam is the logical persistence contract. Enumerate materialized Sessions, load each Session, and serialize the complete header plus ordered events into an operator-owned migration bundle. Keep one manifest row per Session with its ID, parent, event count, first and last sequence, content hash, and export result.

Use synthetic or redacted Sessions to test the exporter first. Session text, tool arguments, tool results, workspace paths, and attachment references may be sensitive; encrypt the bundle and keep it out of source control.

5. Validate before import

Reject an export when an ID is duplicated, sequences are not contiguous from zero, a parent is missing without explanation, a load failed, or the manifest count differs from the source list. Classify a tool call without a result as an unknown side effect rather than evidence that nothing happened.

This validation is where a silent partial export becomes an explicit stop condition.

6. Import into an isolated JSONL root

Start a separate process with alpha.3 and @deepseek-ai/dsh-session-persistence-jsonl. Use a new root. For each validated bundle item, create the header and append the ordered events through the persistence API. Do not write compressed JSONL files by hand: the provider owns headers, format checks, encoding, revisions, and atomic publication.

After import, cold-load every Session and compare the header, event count, sequence tail, parent relationship, and derived conversation surface with the export manifest. Keep tools disabled during the first read-only replay.

7. Cut over with rollback intact

Switch only after the new root passes the acceptance gate. Retain the alpha.2 runtime, immutable SQLite snapshot, logical export, import manifest, and exact rollback command. Once production writes begin on JSONL, never alternate writers between the old and new stores; they will diverge.

Copyable acceptance record

source_release: dsh-v0.1.2-alpha.2
source_commit: 0a53fb55bea101816fa226bb964ae2bed71c343b
source_provider: @deepseek-ai/dsh-session-persistence-sqlite
source_snapshot_sha256: <sha256>
source_sessions: <count>
exported_sessions: <count>
export_manifest_sha256: <sha256>
target_release: dsh-v0.1.2-alpha.3
target_commit: dd6322d604e00eec1ba5e0c8541159906a21094a
target_provider: @deepseek-ai/dsh-session-persistence-jsonl
cold_load_passed: yes|no
surface_parity_passed: yes|no
attachment_inventory_passed: yes|no
unknown_side_effects_reconciled: yes|no
rollback_tested: yes|no
operator: <name>
checked_at: <iso-8601>

Building something? Turn your product page into a show people want to watch with PromoFast —hosted, embeddable, and ready to export.

Common mistakes

Upgrading first because the release says existing content is not deleted. Retained bytes are not readable Sessions in the new build.
Confusing the remaining SQLite search index with the removed authoritative persistence provider.
Treating a live-file copy as a consistent backup while WAL writes are still active.
Expecting /export to convert the legacy SQLite store automatically.
Migrating only visible conversations while losing parents, attachments, spilled data, or unknown tool outcomes.
Mounting source and destination providers in one process and creating two authorities.
Calling alpha.3 stable or installing an unpinned npm tag in the migration environment.

FAQ

Did alpha.3 delete my SQLite database?

No. The official release says existing content is not deleted. The critical limitation is that the current build does not open or migrate databases written by the removed provider.

Is all SQLite support gone?

No. The optional SQLite full-text Session query index and the generic SQLite domain-KV storage provider remain. Neither is a substitute for the removed authoritative Session store.

Can I import the database directly into alpha.3?

Not with a shipped first-party importer at this snapshot. Use a build that still contains the old provider, export the logical header and events, then import through the JSONL provider's persistence contract.

Should every user migrate now?

No. Shipped profiles used JSONL, and alpha.3 is a pre-release. Migrate only if your effective composition selected the removed package; otherwise verify the plugin graph and run ordinary upgrade canaries.