Steps sometimes render below the LLM response when resuming a chat session

[jbcallaghan]

Describe the bug Steps sometimes render below the LLM response when resuming a chat session

To Reproduce I am using a step to stream thinking, this completes before the LLM response and shows correctly during the chat, but if you resume the chat, the step renders below the LLM response.

Expected behavior Expect steps to always render above LLM response

Additional context Tested with Chainlit 2.8.3 and 2.8.4

[dosubot[bot]]

This is a known limitation in Chainlit 2.8.3 and 2.8.4: steps and LLM responses can render out of order when resuming a chat session. The rendering order depends on how the backend processes and sends steps/messages, and on frontend logic. Asynchronous execution (for example, not awaiting tool functions) can cause steps to appear after the main message—even if they were sent first during live chat. Making your tool functions async and always awaiting them helps, but doesn't guarantee perfect order on resume see discussion.

Other factors that can affect rendering order include timestamp inconsistencies (like 'end' before 'createdAt'), parentId filtering in your @on_chat_resume logic, and frontend UI limitations. Ensuring system clocks are synchronized and timestamps are stored in UTC can help prevent ordering bugs details.

There isn't a built-in feature or configuration to pin steps above LLM responses after chat resume. Some users work around this by deleting steps without messages on resume, or by manually refreshing the UI, but these are not official fixes example workaround.

If you need strict control over rendering order, you may need to monitor future Chainlit releases for improvements or consider custom frontend changes.

To reply, just mention @dosu.

---

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

[jbcallaghan]

All tool functions are asynchronous and awaited, but this is not relevant as I am streaming thinking into the step asynchronously, not tool calls. Clocks are not the issue either in this case as the times are correct in backend and fronted. Deleting steps is not applicable as I don't have duplicates and they aren't empty.

[github-actions[bot]]

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