Hi @Xtreemrus,

Thanks for reporting this issue! It looks like Socket.IO (internally using Engine.IO) has a default maximum frame size of 1,000,000 bytes. When we change it in

core.sio = sio = socketio.AsyncServer(async_mode='asgi', cors_allowed_origins='*', json=json,
                                      max_http_buffer_size=10_000_000)

your example works. So we need to think about whether to somehow detect an overflow and warn the user about it, or to provide a configuration option.

What do you think?

Hi @falkoschindler,

Thank you for your reply. I'm glad that the core issue has been identified.

While I'm not a professional developer, it seems the problem consists of two parts:

1. Providing developers with a way to catch and identify the issue. An exception should be raised when the buffer overflow occurs.

2. After notifying the developer about the error, we need to offer a way to fix it.

Possible solutions:
For point 2, it's relatively straightforward and could potentially be addressed by adding an extra parameter to ui.run.

The solution for point 1 is less obvious, at least from my perspective. Since nothing is propagated to the backend during overflow, we could potentially add a JS script to each ui.input field where overflow might occur. This script would check text.value.length, and if it exceeds max_http_buffer_size (which could be passed as a constant to JS at site startup), it would trigger an exception on the Python side.

Simply setting max_http_buffer_size to a very large number and hoping users won't exceed it seems less ideal, as we wouldn't have visibility into how often this event occurs.

In an ideal scenario, it would be great if all input fields where possible had an option to specify the maximum number of characters allowed. If a developer sets an input character count higher than max_http_buffer_size, they would receive a warning during ui.run. This wouldn't be an error, but a caution that it could occur. Additionally, giving developers the ability to call a custom function when buffer overflow happens could help them implement user-friendly messages like "Warning: This field is limited to 1 million characters."

These approaches would provide more robust error handling and improve the developer and end-user experience.

According to the engineio sources, AsyncSocket class raises an exception if it receives too much data:

    async def _websocket_handler(self, ws):
        """Engine.IO handler for websocket transport."""
        async def websocket_wait():
            data = await ws.wait()
            if data and len(data) > self.server.max_http_buffer_size:
                raise ValueError('packet is too large')
            return data

This exception is silently caught elsewhere.

How about core.sio = sio = socketio.AsyncServer(async_mode='asgi', cors_allowed_origins='*', json=json, max_http_buffer_size=float('inf'))? Would it break something?

How about core.sio = sio = socketio.AsyncServer(async_mode='asgi', cors_allowed_origins='*', json=json, max_http_buffer_size=float('inf'))? Would it break something?

I guess this would allow any client to send arbitrarily large packages to the server, which could exhaust the memory and kill the server.

This exception is silently caught elsewhere.

That's bad. But where could this be? Here is the line emitting the socket message:

Any exception caught in loop() should be logged to the console. 🤔

Interesting 🤔

Would say, though: maybe a solution would be to send the difference in string, when the textarea is updated? Then no need to send so many characters across the internet?

But that would be quite difficult and require an intensive rework ...

And it might not even solve the problem if the diff is large, e.g. loading a new text from a file, converting to uppercase, replacing certain characters, translating into another language, minifying code, ... Sure, each example can be considered an edge case. But it's hard to draw a line.

Therefore, I think, the main goal should be to at least raise an exception if a message cannot be sent due to size limitations.

Proposal: Every time we do window.socket.emit in https://github.com/zauberzeug/nicegui/blob/6ad424126b4d6d11e5b5b069e545783d262d2fef/nicegui/static/nicegui.js, we check the length, and warn if it is getting to be too long (earlier than an error would show up, maybe 50% of the max length) so that the user and developer know to stop what they are doing or raise the limit themselves.

Thinking about the socket.io max message length: I think it was set in good faith so that one message will not monopolize the entire communication bandwidth, leading to other clients cannot send message. Maybe we can break up one message into several ones, if it is getting to be too long?

Yes, warning about reaching the size limit or splitting messages are possible solutions.

Nevertheless, I'm still assessing the situation: Why is the following code silently dropping change messages when editing the value?

ui.textarea(value='x' * 1_000_000, on_change=lambda: ui.notify('changed'))

Shouldn't it show any kind of error? Even registering an error handler like this doesn't help:

window.socket.on("error", (err) => console.log(err));

A hint to anyone trying to debug this:

The WebSocket simply gets disconnected, when the super-long message is sent.

Here I will put my solutions I brainstormed:
 

• An immediate approach would be, upon disconnection, check if the last message is super large. If so, show a warning on screen.
• Or, upon reconnection, server reports on which message it has received, and if client sees a message is missing in the list, show a warning on screen.

OK. I came to the conclusion that Python.EngineIO does not have method for setting any extra handler for a too-long WebSocket message. It just throws it silently out the window, terminates the connection, and calls it a day. Zero chance of attaching a handler without modifying upstream.

Look at this:

https://github.com/miguelgrinberg/python-engineio/blob/527e2a944985fc7f63a28169dfe8f4b325287885/src/engineio/async_socket.py#L151-L157

the inner function websocket_wait raises ValueError('packet is too large') if too long.

Then here:

https://github.com/miguelgrinberg/python-engineio/blob/527e2a944985fc7f63a28169dfe8f4b325287885/src/engineio/async_socket.py#L220-L241

You see, if websocket_wait raises an exception, it is caught by the catch-all except: block, which simply breaks the while loop of listening in on WebSocket messages.

Then finally here:

https://github.com/miguelgrinberg/python-engineio/blob/527e2a944985fc7f63a28169dfe8f4b325287885/src/engineio/async_socket.py#L258-L261

It then shuts the WebSocket like usual, as if nothing happened.

The above is confired by strategically placing print statements (idk pdb, sorry)

We then see the following in the terminal when the too-long message is sent:

Found it!
Break here???
Got out of the while loop...

I would call it bad code quality and API design on their part...

This exception is silently caught elsewhere.

That's bad. But where could this be? Here is the line emitting the socket message:

nicegui/nicegui/outbox.py

Line 99 in b4fb23d

await core.sio.emit(message_type, data, room=target_id)
Any exception caught in loop() should be logged to the console. 🤔

Simply put: Now we know. The exception is in the bit bucket. It will never be logged to the console as such.

And yeah, that's indeed bad. Real bad.

Here goes nothing: miguelgrinberg/python-engineio#397

For NiceGUI On Air we had a similar problem and implemented data chunking: #4555

For reference, here is a demo showing

• how the client disconnects when editing the 1MB text (the counter stops),
• the client reconnects after a few seconds (the counter continues),
• but the text stays out of sync between client and server (which still reports the original text length).

textarea = ui.textarea(value='x' * 1_000_000, on_change=lambda: ui.notify('changed'))
ui.label().bind_text_from(textarea, 'value', lambda x: f'{len(x)} characters')

number = ui.number(value=0)
ui.timer(1.0, lambda: number.set_value(number.value + 1))

After reading miguelgrinberg/python-engineio#397 (comment), it seems to come down to the question whether the server is responsible for informing the client about errors (like I would expect from an HTTP server), or if the client needs to comply with certain limits (as it seems to be the case for Socket.IO).

Regarding the issue of lost messages after editing a long text, I don't think handling the disconnect is a good solution. There should be a way notice the problem beforehand, either with help from socket.io or not.

Author of python-engineio seems to be disinterested to be responsible for informing neither the client nor the server about too-long-message errors.

Personally I would not go with that design, but anyways...

Seems like perhaps keeping track of message length on the client side, as well as segmenting, is the way to go so far.

Yeah, so it's our responsibility, engineio is not taking it up.

Let's get to implementing segmenting and prevent the client from ever sending a too-long message in the first place, then.

I'm not so sure we're there yet. Engineio might not be responsible, but maybe the Socket.IO client? It is responsible for serializing and submitting messages. Therefore it should be able to judge the total message size and report an error if it exceeds a limit.

Anyway, would we really want to implement segmenting? Do we really want to allow sending MBs of data back an forth? I still think the primary goal is to inform the user about the message not being transmitted. And it would be great to keep the connection alive.

Well, regardless of doing segmenting or show a warning when too much data, the current response from engineio author (he also make the socketio) seems that he means that "responsibility is on us".

At the end of day we have to add something to our codebase, not him adding something to his.

He is the author of https://github.com/miguelgrinberg/python-engineio and https://github.com/miguelgrinberg/python-socketio. But I'm talking about https://github.com/socketio/socket.io, the JavaScript client.

Anyway, would we really want to implement segmenting? Do we really want to allow sending MBs of data back an forth? I still think the primary goal is to inform the user about the message not being transmitted. And it would be great to keep the connection alive

In my opinion we should make it possible to submit large chunks of text (like it what the this issue describes in the first place), send image data via socketio etc without flooding the websocket connection. Purely increasing the engineio max_http_buffer_size will saturate the channel and block all other messages from passing through. Therefore, implementing segmentation with a maximum chunck size of 0.1 MB or so is required on frontend and backend. Of course we will also need to provide configurable limit for developers to set an upper limit which the server can receive. With #4571 @evnchn already implemented a message which can be shown to the user in such cases.

In my eyes, it is a mixture of techniques:

• 0-0.1MB: message being sent is fast enough, no need show anything.
• 0.1-1MB: Chunked message transmission using chunks of 0.1MB: show a "Loading" popup while the event is being transmitted to the server, which may take a significant time duration. Potentially show how many chunks left (Message sending to server: 3/9): TODO!
• 1MB+: Exceed what is acceptable: show a "Message too long" popup as seen in popup if socket.io message expected to be too long #4571

Though, #4571 is still beneficial without the handling in 0.1-1MB, since at least the websocket isn't closed and re-opened.

And, with the chunked message transmission, we can afford a higher message upper limit (say 50MB) so that we can fix the core issue we are discussing, which is that "updates not going through when ui.textarea contains more than a million characters"?

It won't make 50MB of text show up easily, just so we are clear. It'll probably lag like crazy on any browser, especially mobile, but at least the issue won't be at NiceGUI, then.

And, for the chunked message transmission, preferably the loading popup isn't as obvious as the one in disconnect and #4571.

Perhaps something inspired by streamlit.