commit ada4d653f4 introduced a fix for an
issue described in #649. After mentioned fix frontend performs 2
requests instead of 1.
This fix can be considered as a vol.2 for #649
* feat(front): add confirmation modal when deleting a resource or a variable
* feat(front): add shift bypass
* feat(front): clear callbacks
* feat(front): Add alert to inform user can confirmation modals can be bypassed
* feature(frontend): Failure module
* feature(frontend): Fix wording + Remove advanced tab for failure modules + fix failure module test
* feature(frontend): Fix wording + add toggle in the mini map + stick component at the bottom
* feat(frontend): Add summary to failure module
* feat(frontend): Add support for Failure module in the FlowModuleViewer
* feat(frontend): Add support for FailureModule in the status viewer
* feat(frontend): Fix building issues
* reorganize handle_child
There were a couple issues with the current implementation:
1. When reading stdout and stderr from the child, as soon as we hit EOF
on one we would stop reading from both (line 1420). This could lead
to the return value not being read from the job program.
2. Lines read from stdout and stderr are put into a channel and read
elsewhere with `rx.recv()` (line 1497) but that channel isn't read
until empty. It is only read in the `while !done.load(...)` (line
1449) loop and that loop can stop after any `.store(true, ...)`.
Which happens when the child exits, when the job is cancelled, when
either stdout or stderr reach EOF...
This can be verified by putting `dbg!(rx.recv().await)` or a similar
assertion after the while loop before returning from that function.
It shows the channel still containing log lines on rare occasions.
I was pretty careful in this to maintain the current behaviour; adding
comments to express intention.
One difference in this is that some regular intervals (cancel check and
ping update) should be more regular?
Before...
> at 00ms wait for 10ms
> at 10ms do things for 3ms
> at 13ms wait again for *10ms*
> at 23ms do things again ...
With change...
> at 00ms wait for 10ms
> at 10ms do things for 3ms
> at 13ms wait again but for *7ms*
> at 20ms do things again ...
Which I'm guessing is preferable but I could be wrong.
* renames; interpolate values in log messages
* do `append_logs()` in tokio::task
* tokio::time::interval & close pipe after limit
* clean up comments
Ruben Fiszel
Jakub Kołodziejczak
Faton Ramadani
Christian Paul
Mike
Ádám Kovács
sqwishy