Unexpected Behavior When Updating data selected from a selectbox

Summary

Currently, we are facing unexpected behavior when updating entries that we get from a selectbox which the selectbox loads from Database. The problem occurs after updating the two entries and then attempting to update the third entry. After the updating the second entry and selecting a third entry, the application reverts back to the first entry [index 0 entry]

Upon encountering this issue, the following error is raised:
Part of the stack trace:
“/usr/local/lib/python3.10/site-packages/streamlit/elements/selectbox.py”, line 160, in serialize_select_box
“/usr/local/lib/python3.10/site-packages/streamlit/util.py”, line 131, in index_
ValueError: {‘ID’: 23, ‘Name’: ‘home’, ‘Url’: ‘https://home.com/6.csv’, ‘Country Code’: ‘DE’, ‘Email’: ‘room@home.com’} is not in iterable

Theory is that the issue stems from the ‘index_’ function in the Streamlit library, which is unable to match the updated ‘x’ dictionary with any dictionary in the ‘iterable’ list. Consequently, this mismatch causes the function to raise a ValueError.

After debugging, we identified that the ‘iterable’ list, which stores the database values, is being updated correctly with new values after each update. However, the ‘x’ dictionary retains the old values even after it gets updated in the database. As a result, ‘x’ becomes different from any dictionary in the updated ‘iterable’ list, leading to the ValueError.

as you can see in the video attached, the home entry has been updated from 6.csv to 5.csv, but for some reason when switching to a 3rd entry, the ‘x’ dictionary isnt updated as well.

Attempted Workarounds:

  1. We initially tried using minimal fields in the ‘iterable’ list (ID, name, and country code) to prevent them from being affected by updates. However, this did not resolve the issue.
  2. We also attempted using ‘streamlit.experimental_rerun()’ as a workaround. While this allowed us to update entries, it is not an ideal solution.

Steps to reproduce

Code snippet:

def render_update_tab(self) -> None:
        streamlit.session_state.select_options = self.feeds.reset_index().to_dict(orient="records")
        if not streamlit.session_state.select_options:
            streamlit.error("There are no feed created yet.")
            return

        selected = streamlit.selectbox(
            "Select feed to update",
            options=streamlit.session_state.select_options,
            key="selected",
            format_func=self.format_feeds_to_labels,
        )

        with streamlit.form("update_feed"):
            url = streamlit.text_input("Url", value=selected["Url"])
            partner_email: str = streamlit.text_input("Email", value=selected["Email"] or "")
            status = streamlit.radio("Status", ("active", "not active"), index=1 if selected["Disabled"] else 0)

            id = selected["ID"]
            name = selected["Name"]
            country_code = selected["Country Code"]

            submitted = streamlit.form_submit_button("Submit")
            if not submitted:
                return

            try:
                with get_sql_engine().begin() as conn:
                    ListManagementRepository.update_feed(
                        id, name, country_code, url, partner_email, conn
                    )
                    streamlit.success("Feed Successfully Updated")
                    self.log_action("update_feed", feed_name, country_code, 'cron(55 7,16 * * ? *)', url, event_bridge_state)
                self.refresh_feeds_table()

If applicable, please provide the steps we should take to reproduce the error or specified behavior.

Expected behavior:

No error is raised and when switching to a third feed, we dont get pushed back to the first entry.

Actual behavior:

It raises a value error and we need to re-choose the entry.

Debug info

  • Streamlit version: tested it on streamlit 1.25.0 & streamlit 1.11.1
  • Python version: 3.10
  • Using pyenv
  • OS version: Macos

Additional information

Video of the problem:
issue

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.