Status + answers to your three questions

Using Streamlit
,
2

Hey there, thanks for the detailed status update and for testing so thoroughly! Let’s break down your questions and findings:

1. Is the app healthy now?
No, the session-restore issue persists. Your server-side session write is working, but on reload, the cookie isn’t being read back by Streamlit (via st.context.cookies). This matches known issues where cookies set via JavaScript (not via HTTP Set-Cookie) may not be visible to the Streamlit backend, especially on Community Cloud, due to how the platform proxies and handles WebSocket upgrade requests. There are multiple community reports confirming that cookies set client-side (via JS) are not reliably sent on the WebSocket handshake, so st.context.cookies often returns empty or incomplete results in this scenario. This is a platform limitation, not a bug in your code or dependency set (discussed here, here, and here).

2. Python 3.14 vs runtime.txt
Community Cloud currently supports Python 3.10, 3.11, 3.12, 3.13, and 3.14 (see docs). However, if you specify a version in runtime.txt that is not supported or if the platform changes its default, it may silently fall back to the latest supported version (e.g., 3.14.x) instead of failing the build. This can cause environment drift, especially if your dependencies were built for 3.10. This fallback behavior is not always clearly documented, but it is observed in practice (see docs).

3. _ar_session cookie mechanism
You’re correct: setting cookies via JS (document.cookie) inside a Streamlit component iframe does not guarantee that the cookie will be sent on the WebSocket handshake (/_stcore/stream). Streamlit’s backend (st.context.cookies) only sees cookies present in the initial WebSocket upgrade request, and platform-level proxies or security layers may strip or block these cookies, especially if they are not set via HTTP Set-Cookie headers. This is a known limitation on Community Cloud (see discussion, here, and here). The stripping appears to apply specifically to the WebSocket upgrade request, not to all HTTP requests, but since Streamlit’s session context is tied to the WebSocket, this effectively blocks your use case.

Summary:

  • Cookies set via JS are not reliably visible to Streamlit’s backend on Community Cloud due to platform-level handling of WebSocket upgrade requests.
  • Python version drift can occur if runtime.txt is not honored; Community Cloud may silently use a newer Python version.
  • The cookie-stripping issue is specific to the WebSocket upgrade request, which is what st.context.cookies relies on.

Workarounds:

  • Set cookies via HTTP Set-Cookie headers from the backend if possible (not always feasible in Streamlit).
  • Consider using Streamlit’s built-in authentication or session state mechanisms.
  • Monitor this feature request for native, robust cookie support.

Sources: