chainlit
chainlit copied to clipboard
Custom routes access to chainlit session context
I'm trying to allow custom routes to access chainlit session. For example, I want this curl to show some text in the chat (for simplicity just looking at the latest session, but ideally my request would have some session identifier and security:
curl -X POST http://127.0.0.1:7000/chainlit/notification \
-H "Content-Type: application/json" \
-d '{"text": "hello there"}'
I mount the app just like the proxy example:
mount_chainlit(app=app, target="my_cl_app.py", path="/chainlit")
And then I want my chainlit to process the request:
import json
import chainlit as cl
from fastapi import Body
from session_store import latest_session
from chainlit.server import app
@cl.on_chat_start
async def on_chat_start():
session = cl.context.session
latest_session["session"] = session
await cl.Message("Chainlit is ready to receive notifications!").send()
@app.post("/notification")
async def notification(payload: dict = Body(...)):
message = cl.Message(content=json.dumps(payload))
await message.send()
return {"status": "sent"}
But when my "chainlit/notification" endpoint is hit, I get Chainlit context not found on message.send().
How do I make my endpoint work with a some chainlit session context?
I found 2 similar threads that might be helpful:
-
Running an extended API endpoint with init_http_context() but chainlit API (cl.Message) isn't working - No solution found in the comments.
-
Access a session context from a custom API endpoints - The suggested solution involves passing the session ID to your custom endpoint call and using it to initialize the context, which may help resolve the
Chainlit context not founderror you're encountering.
To continue talking to Dosu, mention @dosu.
Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other
https://github.com/Chainlit/chainlit/issues/315 This used to answer the question, but now it has changed. I wonder if this use case simply needs to be better documented or is the WebApp integration section is the replacement for this use case? Although I don't think it covers it 100%.
This issue is stale because it has been open for 14 days with no activity.
This issue was closed because it has been inactive for 7 days since being marked as stale.