Could you please clarify what is the expected behavior when using a Python Shiny dashboard deployed on Posit Connect Cloud?
While it takes a long time (around 30 minutes) to deploy a Python Shiny dashboard on Posit Connect Cloud (under Python 3.13), my expectation was that the deployment is a container which is then waken up when users click on the link,
However, it appears that, when a new day starts and an user clicks on the dashboard link, the container is rebuilt (for yet another 30 minutes). For some days this rebuilding also happens multiple times a day, when an user clicks on the deployed dashboard link.
Is this an expected behavior?
Thank you
1 Like
Hi @Alex_As ,
No, that doesn't sound like expected behavior. Your understanding sounds about right, basically we generate a container environment when the application is first published. When that application is restarted, the already-generated container environment is used instead and long builds should be bypassed.
Sometimes we see patterns like this when starting the application takes a long time. If you'd like to share the URL I could take a closer look.
Thanks
Mike
Engineer on Posit Connect Cloud
Hi @Alex_As
I investigated this and have found it to be a previously unknown bug in Connect Cloud. (We save the list of your application's dependent Python packages to a database, and your application has a large number of these packages. The database's size limits for the list were exceeded.)
We have logged an issue for our internal development teams to deliver a proper fix for this. In the meantime, you could check your requirements.txt to ensure it only includes packages your code truly needs. If you're able to reduce that list, that could resolve the issue in the short term.
Thanks
Mike
1 Like
Thank you for the investigation.
A clarification, please: is the size limit referring to maximum allowed number of Python packages in requirements.txt, or to the largest allowed size of the generated Python virtual environment?
The size limit that is currently causing issues relates to the number of packages, not the size on disk of the venv.
1 Like
Thank you for clarification.
What is the maximum allowed number of packages in the "requirements.txt" file, such that I can investigate which packages to remove from "requirements.txt" to get under the max allowed number, while maintaining the dashboard functionalities?
There isn't a predictable maximum number unfortunately because the limit is in total number of characters used to express all of the packages, not in total number of items in the list.
I think it is likely we will offer a proper fix for this in the foreseeable future, so I wouldn't recommend herculean efforts to reduce the package count, other than removing any that might have been added extraneously that aren't truly being used.
1 Like
Does the total number of characters used to express all of the packages include characters from both the uncommented lines and commented lines in the "requirements.txt", or only the characters from uncommented lines?
For example, the number of characters in this subset of lines from "requirements.txt" is number of characters of first line only, since this is the only uncommented line?
On a side note, the lines after #via are automatically generated by uv package when running command "uv export --no-hashes --format requirements-txt > requirements.txt"
alive-progress==3.3.0
# via dashboard-qwim-p13
#Commented by me mkdocs-autoapi==0.4.1
# via
# dashboard-qwim-p13
# mkdocs-idm
We're storing lists of packages we found your content needs, not the direct contents of your requirements.txt. So only reducing package count could help.
We are progressing well on an initial improvement that will increase the number of packages that still work correctly. That fix will likely roll out early next week and should help you.
1 Like
We deployed the above - mentioned improvement, although it looks like you also were able to get a sufficiently reduced package count for the built environment to be fully captured.
Good question. I have been working with Shiny dashboards on Posit Connect Cloud and found that the expected behavior depends on the content type. For Python Shiny apps, Connect Cloud provisions a runtime environment and starts the app on first access. There is some cold-start latency (usually 10-30s). For scheduled refreshes, you might need the Connect Server API for programmatic triggering.
1 Like