You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After applying this against a real project it became clear that the guidance is doubly inconsistent:
No data-layer code reads or writes the column. PR feat: Add Modes #2734 only adds modes to the in-memory Step / Message dataclasses and the emitter that pushes mode metadata to the UI. It does not touch backend/chainlit/data/chainlit_data_layer.py or backend/chainlit/data/sql_alchemy.py. Verified on 2.11.0: grep modes on both files returns zero hits. The create_step upsert in ChainlitDataLayer still enumerates exactly: id, threadId, parentId, input, metadata, name, output, type, startTime, endTime, showInput, isError. _convert_step_row_to_dict never populates modes from the row. So even if a user adds the column, nothing is ever stored there.
The table name is wrong for ChainlitDataLayer users. The SQL uses unquoted lowercase steps, which only matches SQLAlchemyDataLayer. The ChainlitDataLayer (which the companion chainlit-datalayer project bootstraps via Prisma) uses quoted PascalCase identifiers — "Step", "Thread", "Element", "Feedback", "User". Running the release-notes SQL against a ChainlitDataLayer database fails with relation "steps" does not exist.
Chainlit/chainlit-datalayer's prisma schema has not been updated to add a modes field to the Step model. A schema bootstrapped from that repo will not have the column either, and there is no migration that introduces it. The chainlit-datalayer repo appears unmaintained (last migration 20250108095538_add_tags_to_thread), which compounds the confusion.
Steps to reproduce
Bootstrap a Postgres schema from Chainlit/chainlit-datalayer (Prisma). The Step table is created as "Step" with the 13 prisma-defined columns.
Upgrade Chainlit to 2.9.4 (or later; 2.11.0 still shows the same behaviour).
Follow the release notes: ALTER TABLE steps ADD COLUMN IF NOT EXISTS modes JSONB;
Observe: ERROR: relation "steps" does not exist.
Fix the table name manually: ALTER TABLE "Step" ADD COLUMN IF NOT EXISTS modes JSONB;
Use the mode API (cl.Message(..., modes={...}), emitter.set_modes), observe the UI works, then inspect the database. SELECT modes FROM "Step" is always NULL — the data layer never writes to it.
Expected
Either:
The release notes accurately reflect what is actually required (which, for ChainlitDataLayer users on the current codebase, is nothing), or
ChainlitDataLayer.create_step and _convert_step_row_to_dict are updated to persist/read modes, the chainlit-datalayer prisma schema is updated to include modes Json?, and the release-notes SQL is corrected to target the right identifier ("Step" quoted, or added via a prisma migration that targets the correct table name).
Summary
The 2.9.4 release notes flag a breaking change and instruct persistence users to run:
(https://github.com/Chainlit/chainlit/releases/tag/2.9.4, pointing to #2734.)
After applying this against a real project it became clear that the guidance is doubly inconsistent:
No data-layer code reads or writes the column. PR feat: Add Modes #2734 only adds
modesto the in-memoryStep/Messagedataclasses and theemitterthat pushes mode metadata to the UI. It does not touchbackend/chainlit/data/chainlit_data_layer.pyorbackend/chainlit/data/sql_alchemy.py. Verified on 2.11.0:grep modeson both files returns zero hits. Thecreate_stepupsert inChainlitDataLayerstill enumerates exactly:id, threadId, parentId, input, metadata, name, output, type, startTime, endTime, showInput, isError._convert_step_row_to_dictnever populatesmodesfrom the row. So even if a user adds the column, nothing is ever stored there.The table name is wrong for
ChainlitDataLayerusers. The SQL uses unquoted lowercasesteps, which only matchesSQLAlchemyDataLayer. TheChainlitDataLayer(which the companionchainlit-datalayerproject bootstraps via Prisma) uses quoted PascalCase identifiers —"Step","Thread","Element","Feedback","User". Running the release-notes SQL against aChainlitDataLayerdatabase fails withrelation "steps" does not exist.Chainlit/chainlit-datalayer's prisma schema has not been updated to add amodesfield to theStepmodel. A schema bootstrapped from that repo will not have the column either, and there is no migration that introduces it. Thechainlit-datalayerrepo appears unmaintained (last migration20250108095538_add_tags_to_thread), which compounds the confusion.Steps to reproduce
Chainlit/chainlit-datalayer(Prisma). TheSteptable is created as"Step"with the 13 prisma-defined columns.ALTER TABLE steps ADD COLUMN IF NOT EXISTS modes JSONB;ERROR: relation "steps" does not exist.ALTER TABLE "Step" ADD COLUMN IF NOT EXISTS modes JSONB;modeAPI (cl.Message(..., modes={...}),emitter.set_modes), observe the UI works, then inspect the database.SELECT modes FROM "Step"is alwaysNULL— the data layer never writes to it.Expected
Either:
ChainlitDataLayerusers on the current codebase, is nothing), orChainlitDataLayer.create_stepand_convert_step_row_to_dictare updated to persist/readmodes, thechainlit-datalayerprisma schema is updated to includemodes Json?, and the release-notes SQL is corrected to target the right identifier ("Step"quoted, or added via a prisma migration that targets the correct table name).Versions checked
chainlit==2.11.0(also reviewed the 2.9.4 release notes / PR feat: Add Modes #2734 diff).chainlit-datalayermainprisma schema, fetched live: nomodes.Related
feat: Add Modes)