[Bug] Android APK: ZodError in workspace.json (updatedAt) blocks app startup after user-initiated stop — sessions locked

[ruslan3030]

Environment:

• Platform: Android (APK build of DeepSeek Harness)
• Device: Poco X3 GT (MIUI)
• Node.js version (from log): v26.4.0
• App package: com.deepseek.harness

Problem:
After stopping the app via Android system settings, the app can no longer start.
The Web UI shows ERR_CONNECTION_REFUSED because the Node.js engine fails to boot.

Error from /sdcard/DeepSeekHarness/dsh-web.log:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): failed to apply loader entry workspace (@deepseek-ai/dsh-workspace): domain 'workspace': stored record 'b9386b7f-4be1-4537-8b99-061036b476bf' in table 'workspaces' does not match its schema

ZodError: [
{
"expected": "string",
"code": "invalid_type",
"path": ["updatedAt"],
"message": "Invalid input: expected string, received number"
}
]

The corrupted record is in workspace.json.
Path inside the app's private data:
/data/data/com.deepseek.harness/files/payload/dshroot/storages/workspace.json

What I've tried (without root):

• Shizuku + MT Manager / MiXplorer → cannot access /data/data/com.deepseek.harness/
• run-as com.deepseek.harness → package not debuggable
• Termux + rish (Shizuku remote shell) → same not debuggable error
• InstallWithOptions → could not install older version over the broken one

The core issue:
The app is not debuggable, so I cannot edit workspace.json manually to change the numeric updatedAt value into an ISO-8601 string. I also cannot reinstall an older version without losing all data.

What I need:

• Is there a way to start the engine in a recovery mode that ignores or repairs invalid workspace records?
• Is there a migration script or a manual fix that can be applied without root?
• Can a future release include a fallback: if a record fails Zod validation, skip it or recreate the cache instead of blocking the entire boot?

I have important session data in the app's private storage that I cannot export. Any guidance would be greatly appreciated.

Attached: (if possible) the full dsh-web.log file.

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): failed to apply loader entry workspace (@deepseek-ai/dsh-workspace): domain 'workspace': stored record 'b9386b7f-4be1-4537-8b99-061036b476bf' in table 'workspaces' does not match its schema

ZodError: [
{
"expected": "string",
"code": "invalid_type",
"path": ["updatedAt"],
"message": "Invalid input: expected string, received number"
}
]

at file:///data/user/0/com.deepseek.harness/files/payload/dshroot/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-storage-domain/lib/index.js:354:157
at parseRecord (file:///data/user/0/com.deepseek.harness/files/payload/dshroot/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-storage-domain/lib/index.js:397:10)
at DomainFacility.open (file:///data/user/0/com.deepseek.harness/files/payload/dshroot/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-storage-domain/lib/index.js:354:94)
at async [cordis.init] (file:///data/user/0/com.deepseek.harness/files/payload/dshroot/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-workspace/lib/index.js:313:18)
... (далее стек вызовов до boot)

Node.js v26.4.0

[PerryLink]

Short answer: on master there is no recovery mode, env flag, or repair script for this — a stored record that fails its schema makes DomainFacility.open throw, the workspace plugin's init fails with it, and the whole plugin tree refuses to load. That matches your stack exactly. The one promising fact I found in source is that the storage layer already ships an opt-in "backup-and-skip" mechanism — the workspace domain just doesn't use it.

Evidence from the master checkout:

• packages/workspace/workspace/src/spec.ts:27 — updatedAt: z.string(), (with createdAt: z.string() at :26). The comment above says "timestamps are ISO-8601 strings".
• Boot path: packages/workspace/workspace/src/index.ts:118-119 — protected async [Service.init](): Promise<void> { const domain = await this.ctx.storageDomain.open(workspaceDomainSpec) .... No try/catch around it, so a validation failure kills init → "plugin tree failed to load".
• The throw is unconditional: packages/storage/storage-domain/src/index.ts:199-211 — parseRecord translates any zod failure into DomainError 'invalid-record', text "domain '${domain}': stored ${slot} does not match its schema" (the exact sentence in your log).
• The opt-in alternative exists but is not wired for workspace: packages/storage/storage-domain/src/spec.ts:57-67 documents invalidRecords?: 'backup-and-skip' — "Absent (the default), the whole open rejects with invalid-record — right for authoritative data." The session projection cache opts in (packages/session/session-projection-cache/src/spec.ts:102); the workspace spec (packages/workspace/workspace/src/spec.ts:68-76) does not. The workspace domain's pendingMutation marker (:33-41) only covers interrupted create/delete mutations, not schema failures.

Practical side, honestly:

• Without root or a debuggable build, editing /data/data/.../workspace.json is effectively blocked on your device — your run-as results are consistent with a release-signed APK. Not verified on-device: whether the APK exposes any export/backup surface, whether adb backup is permitted by the manifest, and whether an older APK would accept a v2 record. The one file you can reach is /sdcard/DeepSeekHarness/dsh-web.log, which suggests the app can write to shared storage — worth checking if any export path lands there, but I can't confirm one exists.
• If you can get the JSON off the device by any means, editing updatedAt to any ISO string (e.g. "2026-01-01T00:00:00.000Z") should satisfy the schema and let boot proceed.
• Worth reporting as an issue: boot should quarantine a bad record instead of dying. The machinery already exists (backup-and-skip), so this looks like a spec opt-in rather than new infrastructure — but I'm not in a position to promise anything.
• Side note: the master writer always stamps ISO strings (packages/workspace/workspace/src/index.ts:508 — updatedAt: new Date().toISOString()), so a numeric updatedAt suggests something else wrote that record. If you ever manage to extract the file, attaching its contents to the report would be very useful.

Happy to dig further if you can share the full dsh-web.log or the record contents.

[ruslan3030]

Thank you, PerryLink. Your analysis is incredibly helpful — it's clear you know Cordis and the DSH internals far better than most, and I really appreciate you taking the time to dig into this.

I understand you're not on the core team and can't promise anything. That said, given your deep involvement in the ecosystem, I wanted to ask a few things:

1. Would you be able to open an issue or PR to enable backup-and-skip for the workspace domain? It sounds like a small spec change, but I don't know if that's the kind of thing you'd want to push upstream.

2. If not, do you know anyone on the core team who might take a look? A nudge from someone with your reputation could make a real difference.

3. Is there any workaround you can think of for a release-signed APK without root — even a long shot? I've already tried Shizuku, MT Manager, MiXplorer, Termux + rish, and iAdb. All blocked by not debuggable. But if you have any other idea, I'm willing to try.

If it helps, I can provide the full 142 MB log, or extract specific sections. I can also share the exact record contents if I ever manage to get them off the device.

Thank you again for your time and for everything you do for the DSH ecosystem.

[ruslan3030]

Hi PerryLink,

Thanks again for the detailed breakdown earlier — it really helped me understand what's going on under the hood.

I'll keep waiting for any update. In the meantime, if you ever happen to remember a workaround for a release-signed APK without root, I'd be glad to hear it. Even a long shot.

No rush at all. Appreciate everything you do for the ecosystem.

[ruslan3030]

Hi PerryLink,

A quick update — the situation changed, but not in the way I hoped.

I installed the latest APK version available for my build (v1.14.0). The app now launches its native console, but the engine still crashes with the exact same ZodError:

domain 'workspace': stored record 'b9386b7f-4be1-4537-8b99-061036b476bf' in table 'workspaces' does not match its schema
ZodError: [{ "expected": "string", "code": "invalid_type", "path": ["updatedAt"], "message": "Invalid input: expected string, received number" }]

So the newer version did not help — the workspace domain still does not opt into backup-and-skip, and the whole plugin tree still refuses to load.

I understand there may be nothing more you can do. I just wanted to close the loop and confirm that your diagnosis was exactly right: the bug is in the core storage layer, not in the APK wrapper.

Thank you again for your time and analysis.

[ruslan3030]

Quick update — I think I may know what caused the corrupted updatedAt.

I asked an agent inside DSH to delete some unnecessary sessions created by the scheduler. The agent reported success, but the sessions still appeared in the UI. It then continued deleting other things and asked me to restart the app. I didn't force-stop it immediately, but did so a bit later. After that, the app never started again.

My hypothesis: the agent itself wrote a numeric updatedAt (Unix timestamp) instead of an ISO string when modifying workspace.json, which broke the schema and caused the boot failure.

This may be a systemic bug in the agent or the storage layer, not a one-off issue.

[ruslan3030]

Thank you so much for your detailed analysis and guidance — it was incredibly helpful.

I'm happy to report that the issue is now resolved. Following the advice from the APK maintainer, I:

1. Exported all data via the console's "Export all data" function.
2. Edited workspace.json inside the zip to change the numeric updatedAt to an ISO string ("2026-09-15T12:59:50.287Z").
3. Cleared app data.
4. Imported the fixed zip back.

The app now boots, and all my sessions are intact. Your diagnosis was spot on — the corrupted record was the root cause.

One additional nuance that might be useful: after the import, I still couldn't create new sessions due to a "waiting for workflowEngine" error. It turned out that only 5 out of 10 plugins were enabled in the console. After enabling all plugins, the error disappeared and new sessions work fine. So it seems some plugins are required for the workflow engine to load.

Thanks again for your time and for everything you do for the ecosystem.