Widgets fail to response after long idling

[koei6666]

Have anyone encountered an issue that after leaving a session running for long hours, some widgets(like ui.table) stop response to interactions like selecting and sorting etc. which leads to crashing the whole process.

I encountered this problem only with the pyinstaller packaged version.

How I encountered the problem is : I started an instance of my app then close the browser and leave the instance running for few hours, when I trying to reaccess the instance from browser the UI initiated normally but the widget like ui.table freezes when I trying to interact with it, and eventually crashes without any tracebacks.

I wonder if there are anyone knows the solution to this problem.

[rodja]

Do you use @ui.page or root function? Or have you simply all ui defined without a builder? Maybe you can share a minimal code example which shows this behaviour?

[koei6666]

Yes, I use ui.page decorator, I'll post a code example in a while

[koei6666]

Hello , @rodja, below is the code sample I use to create the widget( in this case its ui.table):

class CustomTable(ui.table):
    def __init__(self, *, rows, columns = None, column_defaults = None, row_key = 'id', title = None, selection = None, pagination = None, on_select = None, on_pagination_change = None):
        super().__init__(rows=rows, columns=columns, column_defaults=column_defaults, row_key=row_key, title=title, selection=selection, pagination=pagination, on_select=on_select, on_pagination_change=on_pagination_change)
        self.indexed_column_name_dict : Dict[int, str] = None

this issue will only happens if the session is idling for a while( usually for several hours), and after being packaged with pyinstaller.

[falkoschindler]

@koei6666 Unfortunately these few lines of code are not enough to reproduce your problem. This is just a class definition. It's unclear how you set up your app, how you use CustomTable and how you package the app. And what exactly do you mean with "trying to interact with it" and "eventually crashes"?

Here's a short description of an ideal code example:

What is a Minimal Reproducible Example?

An MRE is the smallest, self-contained piece of code (plus exact steps) that someone else can run to see the same problem you’re seeing.

It must be:

1. Minimal – no extra code, packages, or files unrelated to the bug.
2. Complete – nothing missing: import statements, data, config, and precise commands to run it.
3. Reproducible – others can run it and hit the same behavior without guesswork.

[falkoschindler]

For reference, here's a cross-post on reddit where another user reports a similar problem:
https://www.reddit.com/r/nicegui/comments/1o5l6oa/widgets_fail_to_response_after_long_idling/

[BaccanoMob]

I believe it's the same user.

Also, this may be due to #2410. Like idle for too long browser goes into data saver mode, and most likely connection is lost during then.

So far I haven't use my nicegui projects for long idling but I have similar experience with using nicegui on mobile. For example, open nicegui website in android browser, then put the browser in background and work on something else. Open the browser, you will see a connection is reset/lost or similar message. Due to this i can't have unsaved content before putting the browser to background. Workaround i use is open browser as popup.

[falkoschindler]

Good point, @BaccanoMob!
You might want to bind your input elements against user storage. This way the input values would be restored if a browser reconnects after idling.