Flet Client issue when compiled/ build and run for debugging and flutter module integration

[auphof]

Description

I believe there is an issue when building the flet/client for debugging the flet client. It particularly makes it very difficult for further flutter module development in a Linux WSL2 distro.
This issue has been discussed in #2535 where I thought I was just lacking documentation and now I wish to document my understanding of the issue and assist resolving,

NOTE in the additional information I was able to get a VM based instance to build and operate as intended but required a remote ssh session from the VM host to the VM. whilst this could enable current development requirements I believe it should work in the WSL2 instance for general use and simple IDE operation ( please see additional information below)

Code and method example to reproduce the issue:

DEBUG build

1. build and run a debug client with flutter run-d linux --debug in terminal 1
2. a blank window appears with the turning in progress icon. This i believe is expected with a stream of Websocket connection failures in the Terminal
3. create a 2nd Terminal window and cd to the sdk/python/playground
4. config the Flet DEBUG instance to use in the playground export FLET_VIEW_PATH=$HOME/dev/SANDBOX/SANDBOX-flet/modules/flet/client/build/linux/x64/debug/bundle
5. run the playground poetry run flet run main.py -p 8550
6. ❌A 2nd blank window appears with the turning in progress icon., the client in terminal 1 shows connected websockets and responds to key presses [R, h ....etc], but no main.py defined page is drawn
7. in Terminal 2 logging show the connection happening but no message traffic regarding page building

In contrast, if I build the client with the profiling profile

PROFILING build

1. build and run flutter run -d linux --profile in terminal 1
2. a blank window appears (WITHOUT the turning in progress icon). and the terminal sits ideal waiting for a keypress [h,c,q etc...]
3. create a 2nd Terminal window and cd to the sdk/python/playground
4. config the Flet instance to use in the playground export FLET_VIEW_PATH=$HOME/dev/SANDBOX/SANDBOX-flet/modules/flet/client/build/linux/x64/profile/bundle
5. run the playground poetry run flet run main.py -p 8550
6. ✅Flet creates a 2nd window and draws the appropriate page, nothing changes i the first blank window
7. in Terminal 2 logging shows the message traffic regarding the page build

the very simple main.py page definition is in the flet/sdk/python/playground and reads as follows

def main(page: ft.Page):
    flet_session_id = 12
    print(
        f"------------------------------  Main called --- adding to page a ft.Text: session {flet_session_id}"
    )
    page.add(
            ft.Text(f"Hello, World of Flet!, current session is {flet_session_id}")
    )


ft.app(
    main,
    # Disable to test in production format
    # port=8550,
)

Describe the results you received:
see above

Describe the results you expected:

I expect in the WSL2 environment that the page presented in Linux GDI should be drawn and have the hot reloading working for debugging the flutter module integration when using the debug build of a Flet client.

Additional information you deem important (e.g. issue happens only occasionally):

In the logging in terminal 2 i have noticed a slight difference in the socket connection
The line flutter: Connected to: 127.0.0.1:8550 does not appear in the attempt to run the debugging build

in the case of the profiling build

flutter: Connecting to Flet server tcp://localhost:8550...
flutter: Connecting to Socket server tcp://localhost:8550...
flutter: Connected to: 127.0.0.1:8550
flutter: registerWebClientInternal
flutter: Sending: 532
------------------------------  Main called --- adding to page a ft.Text: session 12
flutter: Received packet: 598

and in the case of the debugging build

flutter: Connecting to Flet server http://localhost:8550...
flutter: Connecting to WebSocket server ws://localhost:8550/ws...
flutter: registerWebClientInternal
flutter: New page size: Size(1280.0, 720.0)

additionally I setup a virtual box vm with ubuntu22.04 desktop and have had the same issue, except with 1 working solution
If i ssh into the vm and execute the following it works

1. config the Flet instance to use in the playground export FLET_VIEW_PATH=$HOME/dev/SANDBOX/SANDBOX-flet/modules/flet/client/build/linux/x64/debug/bundle
2. run the playground poetry run flet run main.py -p 8550
3. ✅Flet creates a 2nd window in the vm host with the appropriate page drawn, and the 1st page (from the flutter run --debug) also updates. Both pages draw identically
4. in the SSH Terminal there is no Debug logging, only the print from the main.py (as follows)

➜  playground git:(main) : poetry run flet run main.py -p 8550 -vv
http://127.0.0.1:8550
------------------------------  Main called --- adding to page a ft.Text: session 10
package:media_kit_libs_linux registered.

Flet version (pip show flet):

using cloned from github.com and checkout to 0.22.0
flet                                     0.1.0          /home/fletdev/dev/SANDBOX/SANDBOX-flet/modules/flet/sdk/python/packages/flet
flet-core                                0.1.0          /home/fletdev/dev/SANDBOX/SANDBOX-flet/modules/flet/sdk/python/packages/flet-core
flet-runtime                             0.1.0          /home/fletdev/dev/SANDBOX/SANDBOX-flet/modules/flet/sdk/python/packages/flet-runtime

Give your requirements.txt file (don't pip freeze, instead give direct packages):

N/A and is none in this instance, just plain FLET

Operating system:

WSL2 ubuntu 22.04 distro on Windows 11

Additional environment details:

[auphof]

debug stepping through and comparing why it worked in the VM situation has surfaced a solution.
It is clear the difference is whether the runtime app.py starts up a __run_socket_server or a __run_web_server.
The VM with a remote SSH session was starting a __run_web_server.
It appears the __run_web_server is required for the debugging . It also is apparent from reading the app.py that the env FLET_FORCE_WEB_SERVER can force the __run_web_server .

So in both the WSL2 and the VM instances one can force the correct operation of the client using FLET_FORCE_WEB_SERVER=true poetry run flet run main.py -p 8550.

NOTE: BE AWARE that only the window that resulted from the flutter run -d linux --debug will get the updates from hot reloading of any dart changes after pressing the R in that terminal session. Both Flet GUI (page) windows will get Hot reloads to main.py

This FLET_FORCE_WEB_SERVER env var was introduced in #2700 and made it into 0.21.0. The blog entry https://flet.dev/blog/flet-fastapi-and-async-api-improvements do note this env var FLET_FORCE_WEB_SERVER with others in the major change of from fletd. This blog could possibly do with explanation for it's use in debugging or development of the Flet Client and extensions. I am not totally clear of its ramifications

I think with clarification in documentation this usage fix is acceptable for now as one can work with it.

However for the backlog a simpler debug configuration with reduction of the 2 Flet GUI pages to 1 may be worth considering. This together with the noisy log in flet/client with flutter run -d linux --debug -v hammering with failed connections to the ws server at ws://localhost:8550/ws.... may be worth transferring to Feature request

[ndonkoHenri]

I expect in the WSL2 environment that the page presented in Linux GDI should be drawn and have the hot reloading working for debugging the flutter module integration when using the debug build of a Flet client.

https://github.com/flet-dev/flet/blob/main/CONTRIBUTING.md#restartingrebuilding

So in both the WSL2 and the VM instances one can force the correct operation of the client using FLET_FORCE_WEB_SERVER=true

You actually don't have to do this. As seen from the above contribution file, the command to be run has -w web flag, which does this.