Ideas on Handling API Errors When Populating Selectboxes

Using Streamlit
, , ,
1

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 from selectbox_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 selected
  • selectbox_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:

  1. Selecting a different value in selectbox_1
  2. 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.