[Bug] DSH 0.2.0-rc.2 crashes (SIGABRT, exit 134) during session format v3→v4 migration — and older pinned versions can no longer read the store

[aavainer]

RU: [Баг] DSH 0.2.0-rc.2 падает (SIGABRT, exit 134) при миграции формата сессий v3→v4 — а старые закреплённые версии больше не читают хранилище

Environment

Item	Value
Product	DSH (preview) — DeepSeek Harness, @deepseek-ai/dsh
Version	0.2.0-rc.2 (crashing); 0.1.5-rc.3 (older pinned, cannot read the new format)
OS	Windows, Node.js
Component	session journal format migration v3→v4 (dsh-session-format-v3-to-v4)

Summary

npx @deepseek-ai/dsh web (resolved to 0.2.0-rc.2) crashed with exit code 134 (128+6, SIGABRT) during/after migrating session journals from the v3 to the v4 format. About 157 session.v4.jsonl.zstd files were written to the store before the crash.

Two compounding problems:

1. The crash itself — SIGABRT with no Windows Application-Error event and no captured stderr (the process was running in a foreground terminal, so its stderr was lost). Not reliably reproducible (one episode so far).
2. A silent breaking format change — the older 0.1.5-rc.3 does not ship the dsh-session-format-v3-to-v4 package, so it cannot read the migrated v4 journals. After a restart with the older pinned version, the web UI showed an empty sidebar (no workspaces, no sessions) — no explicit "this store was migrated to v4, upgrade required" error.

No session data was lost (all sessions reappeared after re-pinning to 0.2.0-rc.2), but the crash combined with the format incompatibility forced a full machine reboot and a manual version re-pin.

Steps to reproduce

1. Run 0.2.0-rc.2 against a store that still contains v3 session journals.
2. The migrator converts some journals to v4 (session.v4.jsonl.zstd).
3. The process aborts with exit 134 during/after the migration (observed once; not deterministic).
4. Restart with 0.1.5-rc.3: the sidebar is empty because 0.1.5-rc.3 lacks the v3-to-v4 migrator and cannot read v4 journals.

Expected vs Actual behavior

	Expected	Actual
Migration v3→v4	Atomic, crash-free, transactional	SIGABRT mid-migration; partial v4 files left on disk
Older version reading a migrated store	Clear error ("store migrated to v4, upgrade required")	Empty sidebar, silent
Crash diagnostics	Windows event log / persistent stderr	No event, stderr lost (foreground terminal)

Impact

• Full server outage; the crash required a machine reboot.
• A version mismatch silently strands the workspace: an older pinned version shows an empty sidebar instead of an explicit upgrade message.
• Risk of similar breakage for any user who pins an older version and later runs a newer one that migrates the store.

Suggested fix

1. Investigate the SIGABRT in the v3→v4 migrator (native abort / OOM during migration).
2. Make the format migration atomic and crash-safe (write-then-swap with verification, same as the earlier v0→v3 path).
3. When an older version encounters v4 journals it cannot read, fail loudly ("store migrated to v4, upgrade required") instead of rendering an empty sidebar.
4. Persist server stderr to a log file even in foreground mode, so native crashes are diagnosable.

---

[Баг] DSH 0.2.0-rc.2 падает (SIGABRT, exit 134) при миграции формата сессий v3→v4 — а старые закреплённые версии больше не читают хранилище

EN: [Bug] DSH 0.2.0-rc.2 crashes (SIGABRT, exit 134) during session format v3→v4 migration — and older pinned versions can no longer read the store

Окружение

Параметр	Значение
Продукт	DSH (превью) — DeepSeek Harness, @deepseek-ai/dsh
Версия	0.2.0-rc.2 (падает); 0.1.5-rc.3 (старая закреплённая, не читает новый формат)
ОС	Windows, Node.js
Компонент	миграция формата журналов сессий v3→v4 (dsh-session-format-v3-to-v4)

Краткое описание

npx @deepseek-ai/dsh web (резолвится в 0.2.0-rc.2) аварийно завершился с кодом 134 (128+6, SIGABRT) во время/после миграции журналов сессий из формата v3 в v4. До падения на диск было записано ~157 файлов session.v4.jsonl.zstd.

Две усугубляющие проблемы:

1. Сам краш — SIGABRT без события в Windows Application log и без сохранённого stderr (процесс шёл в foreground-терминале, stderr потерялся). Воспроизводится недетерминированно (пока один эпизод).
2. Молчаливый ломающий смену формата — старая 0.1.5-rc.3 не содержит пакет dsh-session-format-v3-to-v4, поэтому не читает мигрированные журналы v4. После рестарта со старой закреплённой версией веб-интерфейс показал пустой сайдбар (ни воркспейсов, ни сессий) — без явной ошибки «хранилище мигрировано в v4, требуется обновление».

Данные сессий не потеряны (все сессии вернулись после пере-закрепления на 0.2.0-rc.2), но краш в связке с несовместимостью формата вынудил полную перезагрузку машины и ручное пере-закрепление версии.

Шаги воспроизведения

1. Запустить 0.2.0-rc.2 на хранилище, где ещё лежат журналы сессий v3.
2. Мигратор переводит часть журналов в v4 (session.v4.jsonl.zstd).
3. Процесс аварийно завершается с кодом 134 во время/после миграции (наблюдалось один раз; не детерминировано).
4. Перезапуск с 0.1.5-rc.3: сайдбар пуст, т.к. 0.1.5-rc.3 не имеет мигратора v3-to-v4 и не читает журналы v4.

Ожидаемое vs фактическое поведение

	Ожидается	Фактически
Миграция v3→v4	Атомарная, без крашей, транзакционная	SIGABRT посреди миграции; на диске остаются частичные v4
Старая версия читает мигрированное хранилище	Явная ошибка («хранилище мигрировано в v4, обновитесь»)	Пустой сайдбар, молча
Диагностика краша	Событие Windows / персистентный stderr	Нет события, stderr потерян (foreground-терминал)

Влияние

• Полный простой сервера; краш потребовал перезагрузки машины.
• Несовпадение версий молча «глушит» воркспейс: старая закреплённая версия показывает пустой сайдбар вместо явного сообщения об обновлении.
• Риск аналогичной поломки для любого, кто закрепил старую версию, а затем запустил новую, мигрирующую хранилище.

Предложение по исправлению

1. Разобраться с SIGABRT в миграторе v3→v4 (native abort / OOM при миграции).
2. Сделать миграцию формата атомарной и crash-safe (write-then-swap с верификацией — как в прежнем пути v0→v3).
3. Когда старая версия встречает журналы v4, которые не умеет читать, — громко падать с «хранилище мигрировано в v4, требуется обновление», а не рисовать пустой сайдбар.
4. Писать stderr сервера в лог-файл даже в foreground-режиме, чтобы нативные краши были диагностируемы.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[chrishotza]

Я посмотрел именно текущий код миграции и здесь есть один важный момент.

Предложение про write-then-swap, похоже, уже реализовано в текущем session-persistence-jsonl: миграция пишет новую generation во временный файл, делает sync, прогоняет её через отдельную проверку Worker, перепроверяет revision исходного файла и только потом делает эксклюзивную публикацию v4. Поэтому сами по себе 157 файлов session.v4.jsonl.zstd после падения не означают, что публикация была неатомарной — атомарность здесь действует на уровне одной Session generation, а не на весь store сразу.

А вот проблема со старой версией выглядит вполне определённой.

В listArtifacts() неподдерживаемый формат сейчас фактически проглатывается:

if (error instanceof SessionFormatUnsupportedError) continue

То есть 0.1.5-rc.3, встречая уже существующий v4, не сообщает наверх, что хранилище содержит формат новее текущего. Эта Session просто исключается из discovery. Если после миграции большая часть или всё хранилище уже состоит из v4, UI вполне может получить пустой список и показать пустой sidebar вместо ошибки.

Мне кажется, здесь лучше вообще не смешивать два разных состояния:

• повреждённый журнал;
• журнал корректный, но записан более новой версией.

Для второго случая уже есть SessionFormatUnsupportedError, и его стоит сохранять как состояние несовместимости store, а не превращать в обычное отсутствие Session.

Например, при наличии хотя бы одной v4 generation, которую текущий runtime не умеет читать, старый runtime должен либо вернуть явный upgrade required, либо показать отдельное состояние вроде store format v4 requires a newer DSH, вместо того чтобы молча скрывать Session.

А вот с самим SIGABRT я бы пока не называл причиной OOM или native abort без dump. В текущем migration path есть потенциально большой memory peak: сначала восстанавливается полный migrated artifact, затем staged generation снова полностью проверяется Worker'ом. Это хорошее место для измерения RSS/heap и размера artifact.events, но этого недостаточно, чтобы уже сейчас объявить OOM доказанной причиной.

Так что я бы разделил исправление именно так:

1. сохранить SessionFormatUnsupportedError на discovery/listing и явно показать несовместимость store;
2. добавить crash diagnostics для migration: source size, event count, migrated event count, staged size, RSS/heap до/после encode и Worker verification;
3. отдельно воспроизвести миграцию большого v3 журнала и посмотреть, растёт ли память именно на этапе artifact -> staged -> Worker verify.

Это позволило бы не гадать насчёт SIGABRT и одновременно точно закрыть уже подтверждённый баг с пустым sidebar.

[aavainer]

Thanks for the precise code-level review.

Empty sidebar — agreed: SessionFormatUnsupportedError → continue is indeed the root; your fix (keep the error at discovery and explicitly show «store format v4 requires a newer DSH») is the right one. We've recorded it as a confirmed bug on our side; the workaround is to update the pin to a version that reads the new format.

SIGABRT — unfortunately we have no dump: the crash happened on a manual foreground-terminal launch, and stderr wasn't captured. We'll take your measurement plan (RSS/heap across the artifact → staged → Worker verify stages) as the basis; if we reproduce a large v3-log migration with diagnostics, we'll follow up with numbers.

---

RU:

Спасибо за точный разбор по коду.

Пустой sidebar — согласны: SessionFormatUnsupportedError → continue и есть корень; ваш фикс (сохранять ошибку на discovery и явно показывать «store format v4 requires a newer DSH») — правильный. У себя зафиксировали как подтверждённый баг; обход — сразу обновлять pin до версии, читающей новый формат.

SIGABRT — дампа, к сожалению, нет: краш случился при ручном запуске в foreground-терминале, stderr не сохранился. Вашу схему замеров (RSS/heap на этапах artifact → staged → Worker verify) берём за основу; если воспроизведём миграцию большого v3-журнала с диагностикой — дополним цифрами.

[chrishotza]

Glad that helped.

I agree that separating the confirmed format-compatibility bug from the still-unconfirmed SIGABRT is the right approach. The RSS/heap measurements across artifact → staged → Worker verification should make it much easier to tell whether the migration is actually hitting a memory peak or whether the abort is coming from somewhere else.

Once you have a reproducible run with the diagnostics, I'd be happy to take another look at the numbers and help narrow down the failure point.