2.10.0 - Fail To Resume Some Threads - Cannot read properties of null (reading 'startsWith')

[mihidumh]

Describe the bug
Since upgrading from 2.9.6 to 2.10.0 , some old threads do not load.
Error: Cannot read properties of null (reading 'startsWith')

Console errors:

DETAIL:  Failing row contains (9cb39e96-89b9-474d-af87-fb4fd1359bc6, 2026-03-06 02:16:51.353, 2026-03-06 13:16:45.756, null, null, null, null, {}).
2026-03-06 13:16:45,768 | chainlit | ERROR  | Database error: null value in column "metadata" of relation "Thread" violates not-null constraint
DETAIL:  Failing row contains (9cb39e96-89b9-474d-af87-fb4fd1359bc6, 2026-03-06 02:16:51.357, 2026-03-06 13:16:45.76, null, null, null, null, {}).
2026-03-06 13:16:45,769 | asyncio | ERROR  | Task exception was never retrieved
future: <Task finished name='Task-329' coro=<ChainlitDataLayer.update_step() done, defined at /home/mihidum/vscode/chatbot/.venv/lib/python3.13/site-packages/chainlit/data/utils.py:10> exception=NotNullViolationError('null value in column "metadata" of relation "Thread" violates not-null constraint')>

To Reproduce

1. Using official Chainlit Datalayer and Postgres server.
2. Try to resume an old thread.

Expected behavior
Thread resumes and loads.

Screenshots

Might be related to #2778 ?

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[dosubot]

This issue appears to have two separate but related problems:

1. The "startsWith" Frontend Error

The Cannot read properties of null (reading 'startsWith') error likely originates from WelcomeScreen.tsx:58, where .startsWith() is called on a chat profile icon without null checking. If your chat profile has a null icon property, this would trigger the error during thread resumption. Other components like Starter.tsx use proper optional chaining (starter.icon?.startsWith), but WelcomeScreen.tsx may be missing this protection.

2. The Metadata NOT NULL Database Error

Yes, this is related to #2778 — but interestingly, PR #2778 was included in 2.10.0 specifically to fix metadata preservation issues. The fix prevents update_thread() from overwriting existing metadata with null when metadata isn't explicitly provided.

However, if your old threads already have corrupted/null metadata from before the fix, they may still fail to load. As a workaround, you could try updating the affected threads directly in your database:

UPDATE "Thread" SET metadata = '{}' WHERE metadata IS NULL;

There's also an open PR #2799 targeting additional thread resumption robustness that may address some of these edge cases.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[mihidumh]

@dosu Copilot generated this migration file, does it do the same thing?

UPDATE "Thread"
SET "metadata" = '{}'::jsonb
WHERE "metadata" IS NULL;

ALTER TABLE "Thread"
ALTER COLUMN "metadata" SET DEFAULT '{}'::jsonb;

ALTER TABLE "Thread"
ALTER COLUMN "metadata" SET NOT NULL;

it's also updated the datalayer prisma as such:

metadata Json    
to:
metadata Json     @default("{}")

[dosubot]

Yes, that migration does achieve the same goal of fixing null metadata values — it's actually more thorough! Here's a breakdown:

1. UPDATE "Thread" SET "metadata" = '{}'::jsonb WHERE "metadata" IS NULL; — This fixes existing null rows (same as my suggestion)
2. ALTER COLUMN "metadata" SET DEFAULT '{}'::jsonb; — This ensures future rows default to an empty JSON object
3. ALTER COLUMN "metadata" SET NOT NULL; — This adds a NOT NULL constraint to prevent future nulls

The Prisma schema change (metadata Json @default("{}")) aligns with steps 2 and 3.

One note: The current Chainlit schema actually defines metadata as nullable without a default, so your migration is stricter than the upstream schema. This should work fine and prevent this class of errors going forward, but be aware that if Chainlit's default schema changes in future versions, you may need to reconcile any differences.

This migration should resolve the database-side NOT NULL violation error. If you're still seeing the frontend startsWith error after applying this, that would be a separate issue related to chat profile icon null checking.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[mihidumh]

Still an issue