Situation:
I have a Streamlit app with a series of 3 dependent selectbox
components.
- When the user selects an option from
selectbox_1
, an API request is made to a third-party service using that selection as input. - The results from this request populate
selectbox_2
. - The same pattern follows for
selectbox_3
, based on the selection fromselectbox_2
.
Problem:
If the API call fails (e.g., during the step from selectbox_1
to selectbox_2
), the user ends up in a “limbo” state:
selectbox_1
is populated and selectedselectbox_2
has no options (due to the failed API call)- The app currently doesn’t provide a way to retry or recover from this, except by refreshing the page
In practice, users may have already made several other inputs before the failure. Forcing a full refresh would make them redo everything, which is not ideal.
Goal:
Allow the user to recover from an API failure without refreshing the page or redoing prior inputs. Ideally, this should require minimal user action and not feel like a workaround.
Current Workaround:
The user can re-trigger the failed call by:
- Selecting a different value in
selectbox_1
- Then re-selecting their original choice
This forces a new API request, but it’s not a user-friendly solution.
Current Idea:
Track the last API call’s intent and parameters in st.session_state
. If a failure occurs, dynamically render a “Retry” button that allows the user to reattempt the last failed request.
Question:
Has anyone encountered and solved a similar issue? Are there any alternative or more elegant approaches for managing failed intermediate API calls in Streamlit?
Note: I’m already using a retryable HTTP client to reduce the chances of failure, but some edge cases are unavoidable.