ProgressBar ETA goes adrift if a progress bar is "reused"

[davep]

Given this code:

from asyncio import sleep

from textual import on, work
from textual.app import App, ComposeResult
from textual.widgets import Button, ProgressBar

class ReuseProgressApp(App[None]):

    def compose(self) -> ComposeResult:
        yield Button("Count 10 seconds")
        yield ProgressBar()

    @on(Button.Pressed)
    def start_count(self) -> None:
        progress = self.query_one(ProgressBar)
        progress.total = 100
        progress.progress = 0
        self.count()

    @work
    async def count(self) -> None:
        for _ in range(100):
            self.query_one(ProgressBar).advance()
            await sleep(0.1)

if __name__ == "__main__":
    ReuseProgressApp().run()

the first time it's run, the estimated time left is about right:

Screen.Recording.2024-02-01.at.15.31.29.mov

However, once finished, if the button is pressed again, the estimated time starts much higher, initially showing around 20 minutes.

Screen.Recording.2024-02-01.at.15.32.02.mov

Used again, it starts higher still, initially showing over an hour:

Screen.Recording.2024-02-01.at.15.32.27.mov

This is very heavily related to #4054 and will be fixed as part of the work on that; but I'm recording it as an issue in its own right in case anyone runs into this in the mean time. I suspect this will be a good catalyst for reworking the "ETA" calculation from scratch.

I also suspect that ProgressBar should probably acquire some form of "reset" method so it can be put back in an initial state.

[willmcgugan]

@davep Some of this behaviour can be explained by the worker not having exclusive=True. Every time the button was pressed you would get a new worker that was advancing the progress.

This did identify a bug in my recent eta update though. Setting the total via its reactive wasn't working properly.

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.