Streamlit balloons not working in callback for function decorated with fragment

[happinessbaby]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

I wrote a test code to show balloons in the callback of a function with st.fragment decorator, but it's not showing anything. Below is my reproducible test code. In my actual code, the balloons show halfway and keep on rerunning even though the print line before the st.balloon() call is printed only once.

I'm not sure if it's expected behavior if the balloons don't work in the callback of a fragment. In the test code the balloons don't appear while in my actual code the balloons appear nonstop.

Reproducible Code Example

import streamlit as st

def callback():
    call = st.session_state.test_balloons
    if call:
        print("AAAAAAAAAAA") ## this gets printed
        st.balloons()  ## NO BALLOONS

@st.fragment   ## if I comment out st.fragment, it works
def test():
    button = st.toggle("turn on balloons", on_change=callback, value=True, key="test_balloons")
    # if button: <- These lines work if I uncomment them
    #     st.balloons()

test()

Steps To Reproduce

1. Run the code as is, there are no balloons when you turn off the toggle then turn it back on
2. Comment out st.fragment and it works
3. It also works without using callback

Expected Behavior

Balloons should work in the callback of functions with st.fragment decorator

Current Behavior

No balloons appear when toggle is turned on for balloons in callback

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

• Streamlit version: 1.39.0
• Python version: 3.10
• Operating System: Linux
• Browser: Chrome

Additional Information

No response

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[lukasmasuch]

I tried to reproduce the issue here. But it almost seems to work as expected. Only the first interaction with the toggle does not seem to trigger the balloons. Can you share a video on how it looks for you?

[happinessbaby]

okay, that's strange, because for me it's showing nothing no matter how I switch the toggle. I noticed for your reproduction, the balloon appear even the toggle is switched off. (after you switch it on off the first time)

[lukasmasuch]

I was able to reproduce this issue locally. It seems that there is an issue with the interaction of fragments, balloons, and callbacks. But not sure why it doesn't work.

[raethlein]

I have looked into this and here is a workaround:

import streamlit as st

balloons_placeholder = st.empty()

def callback():
    call = st.session_state.test_balloons
    if call:
        print("AAAAAAAAAAA") ## this gets printed
        balloons_placeholder.balloons() 
    else:
        balloons_placeholder.empty()

@st.fragment   ## if I comment out st.fragment, it works
def test():
    button = st.toggle("turn on balloons", on_change=callback, value=True, key="test_balloons")

test()

Actually, it does not only affect st.balloons but all st.* commands that are executed within a fragment-registered callback. The root cause is that callbacks are executed outside of the fragment context here, where the delta path index starts from 0. Then, the fragment code is executed based on the context snapshot when the fragment was created. The balloons did not exist when the fragment where created, but instead the fragment-toggle button in this example started at index 0 as well. So the balloons are overridden by the toggle element with the same index.

The workaround here is that we have an empty element within the main app path which exists even when the fragment is created. Since we write into an existing container, the context snapshot for the fragment contains the empty-container, so the toggle button starts at index 1 and not 0. Thus, the toggle does not override the container.

The right thing to do here likely would be to run callbacks that were registered within a fragment run in the fragment context and, thereby, let it write into the fragment container. Though I hope the workaround is sufficient for now!