Closed rayman2000 closed 7 months ago
Due to the "Verification of" and the progress bar, this is almost certainly a broken progress update (and not a broken finished or abort update). The number is formatted here: https://github.com/viperproject/viper-ide/blob/197805c348e3ba3442334d9183f59fe1db463bf6/client/src/Helper.ts#L55-L58 The formatting helper checks for below 0 but not above 100. Seem like ideally neither would ever get to here.
formatProgress is called from updateProgressLabel, which is called from here:
We either use the provided data.progress or data.current / data.total if data.progress does not exist. data.current and data.total are never set in any caller, so data.progress must be set incorrectly. data.progress is always the return value of getProgress.
If we assign to progress here, then we are below 100. So the input must already be wrong and the timing is also messed up so that we do not reassign.
We call getProgress
either with lastProgress
(which is only set in getProgress
, so can not be the origin of a too high number) or by the params in a StateChangeParams
. So it looks like we can only get a number over 100 from ViperServer, we can not produce it in the IDE and we additionally need the timing stuff to be such that progress is not assigned to in getProgress
.
Progress is updated in ProgressCoordinator
. In theory, it might be possible to receive too many BackendOutputs, making current
go higher than total
.
Strangely, updateProgress is only ever called with BackendOutputType.FunctionVerified.
Important interlude:
A Sink that materializes into a Publisher
It looks like a ProgressCoordinator
is unique per FileManager
, not per RelayActor
. So if a new verification task is started, it will overwrite the progress coordinator, which may still receive EntitySuccessMessage
s from the original verification task.
We can hopefully fix this by moving the progress coordinator into the relay actor instead of the file manager, but unless we can reproduce the error, it is hard to be sure that this actually solves the problem.
There is an easy fix: just force the output of progress to be <100, setting it to 99 if necessary. This will fix the display of the IDE, but not the underlying problem. Since the problem seems to be exceedingly rare, I do not think we should do this.
It looks like a
ProgressCoordinator
is unique perFileManager
, not perRelayActor
. So if a new verification task is started, it will overwrite the progress coordinator, which may still receiveEntitySuccessMessage
s from the original verification task. We can hopefully fix this by moving the progress coordinator into the relay actor instead of the file manager, but unless we can reproduce the error, it is hard to be sure that this actually solves the problem.
I got a file where this seems to be consistently happening. At least at my end it stays stuck on 102%.
I've seen it more often as well.
@sakehl
So for me this file times out at 99% (I may need beefier hardware). Does this also happen the first time you verify a file after reloading or only in later attempts? Our current assumption is something to do with caching, but if it happens the first time then it is probably something else.
When I loaded the file as new I immediately got this. So the first time.
I disabled caching and the same happens. This is what ViperServer output gives:
All right thank you! Just FYI, this is mostly just a visual glitch. Your program is very likely timing out on the backend, the IDE should be showing 99%. If this is blocking you somehow then maybe set the time-out up or look into matching loops or so. (Maybe this was already clear, I just wanted to make sure).
See This occurred when editing a file that was currently being verified. It is not reproducible yet.