noticing 'client_disconnect' event doesn't work while background task is running in the loop

[Roz-floatic]

Hello,
I would like to use your framework to create a real-time dashboard.
Here is how it works:
When a user opens the page, a background task continuously fetches DB data from the server periodically.
However, this task runs indefinitely, and even if the user closes the window, it continues to run (specifically, it is retriggered by a "/" request when the window is closed). Of course, one could use a method to prevent it from running automatically upon a "/" request, but I would prefer to control it by detecting the 'system.client_disconnect' event. However, it seems that this event is not properly detected while the background task is running. Is there an alternative approach to detect it in such a scenario?

[mturoci]

Hi @Roz-floatic!

The background job should not have any effect on disconnected event which makes me think your job may be blocking and is not background at all. Could you maybe create a min repro example so that we have something tangible to discuss?

When a user opens the page, a background task continuously fetches DB data from the server periodically.

Is the data displayed scoped to user or are global (every user sees the same data)?

[mturoci]

Uff, that's much more than "minimal". Will check on Monday as I am pretty busy today and get back to you.

[mturoci]

Although, at first glance, I am not sure why you need both process executor and asyncio. I would try this:

    q.client.future = asyncio.ensure_future(update_data(q))

    try:
        await q.client.future
    # Handle cancellation.
    except asyncio.CancelledError:
        print("cancelled")

[Roz-floatic]

Yes, it's true that I may have written it redundantly as I referenced multiple documents. However, even if I handle it as you suggested, it still seems like the event is not being detected when I close the window.

[mturoci]

Okay, found the problem: The code above was creating an infinite loop on client initialization, which is fine as long as it uses asyncio.sleep that can suspend asyncio task execution. However, the problem was that the code never ran beyond the init function (due to infinite loop) thus could not mark the client initialization as done (q.client.initialized = True). This caused 2 problems:

• Every user interaction (serve function call) spawned another update infinite loop - after 3 button clicks you would have 4 update loops doing the same update.
• Since the code execution could not pass beyond init function, the run_on would never be called, thus neither routing, nor disconnected handler would work.

She solution is simple - move initialization done marker before init call.

    if not q.client.initialized:
        q.client.initialized = True
        q.client.cards = set()
        await init(q)

Full minimal code

import asyncio
from h2o_wave import main, app, Q, ui, on, run_on
from typing import Optional, List
import random


def add_card(q, name, card) -> None:
    q.client.cards.add(name)
    q.page[name] = card


# Remove all the cards related to navigation.
def clear_cards(q, ignore: Optional[List[str]] = []) -> None:
    if not q.client.cards:
        return

    for name in q.client.cards.copy():
        if name not in ignore:
            del q.page[name]
            q.client.cards.remove(name)


async def update_data(q: Q):
    while True:
        await asyncio.sleep(2)
        q.page["cpu_usage"].data = dict(disp=random.uniform(0, 100.0), below_disp="")
        await q.page.save()


@on("#page1")
async def page1(q: Q):
    clear_cards(q)

    add_card(
        q,
        "cpu_usage",
        ui.tall_gauge_stat_card(
            box=ui.box(
                "main",
                height="120px",
                width="33%",
            ),
            title="cpu usage",
            value="={{intl disp minimum_fraction_digits=2 maximum_fraction_digits=2}}%",
            aux_value='={{intl below_disp style="unit" minimum_fraction_digits=2 maximum_fraction_digits=2}}',
            plot_color="$red",
            progress=0.0,
            data=dict(disp=0.0, below_disp=""),
        ),
    )

    q.client.future = asyncio.ensure_future(update_data(q))

    try:
        await update_data(q)
        print('ASYNCIO DONE')
    # Handle cancellation.
    except asyncio.CancelledError:
        print("cancelled")


async def init(q: Q) -> None:
    q.page["meta"] = ui.meta_card(
        box="",
        layouts=[
            ui.layout(
                breakpoint="xs",
                min_height="100vh",
                zones=[ui.zone("main")],
            )
        ],
    )

    # If no active hash present, render page1.
    if q.args["#"] is None:
        await page1(q)


@on("@system.client_disconnect")
async def on_client_disconnect(q: Q):
    print("DISCONNECTED")


@app("/")
async def serve(q: Q):
    # Run only once per client connection.
    if not q.client.initialized:
        q.client.initialized = True
        q.client.cards = set()
        await init(q)

    # Handle routing.
    await run_on(q)
    await q.page.save()

[Roz-floatic]

I confirmed that changing the order allowed me to detect events including the 'client_disconnect' event. However, the issue I was trying to resolve was to automatically stop the code running in the background as an infinite loop when the window is closed. It seems difficult to solve it just by detecting and using this event. Essentially, the loop is automatically restarted when the window is closed because it makes an automatic call to '/'. I was trying to handle it by detecting the 'disconnect' event, but I prefer to address it through user interaction rather than having the code execute automatically. If it's possible to have the window close trigger a '/disconnect' call, that would be great. Is it feasible?

By the way, it seems that this framework is a great dashboard framework for rapid prototyping. I appreciate your work in its development and maintenance.

[mturoci]

I was trying to handle it by detecting the 'disconnect' event, but I prefer to address it through user interaction rather than having the code execute automatically. If it's possible to have the window close trigger a '/disconnect' call, that would be great.

Not sure I understand this one. Could you elaborate? The original idea was to simply cancel the bg task in disconnect event and that's it. If stored in q.client, should be a no-brainer. Or maybe I am missing something?

this framework is a great dashboard framework for rapid prototyping. I appreciate your work in its development and maintenance.

Thanks for the kind words :)