Status > Filter Reload page is confusingly worded
The way the Filter Reload page is displayed implies that the filter rules are loaded by simply visiting the page.
The initially shows:
"This page will automatically refresh every 3 seconds until the filter is done reloading."
then after 3 seconds shows:
"Done. The filter rules have been reloaded".
But the filter rules are not actually reloaded until the button is pressed.
Uhm, dunno guys, it appears to me like this made the thing basically no-op? Previously, it's been showing what's going on during the reload. Now, it shows absolutely nothing, until you - quite a bit later, get "Done. The filter rules have been reloaded." Also, when when you get there via clicking the link shown after changing firewall rules and clicking apply, it basically does not even do the above. It shows totally nothing, just the "Reload" button.
I'd definitely prefer the "confusing" state.
#5 Updated by Steve Beaver 3 months ago
Previously when visiting the page from the status menu the page would say that it was reloading the filter then after three seconds say that it was done. That was not true. It looked like it was reloading hte filter, but it was really only updating the display.
Now you no longer get that fake display. When you click the button it reloads the filter and once finished, displays the "done" banner. Isn't that an improvement?
The clicking the button in the apply process is broken. I'll fix that.
I'm very sure the thing has actually been displaying real activity during reload. Such as, loading the various package firewall hooks, etc. Not anything fake. So now, it shows nothing, no idea where did the output go. It also does not refresh after 3 seconds, e.g. on an APU2 it takes some 10 seconds where it appears there's nothing going on at all (will probably make users click the button over and over again), then all of a sudden it shows "Done. The filter rules have been reloaded."
#8 Updated by Steve Beaver 3 months ago
The root cause of the issue was that the filter reload process over-wrote the status file with every message, so there was only ever one line to read. On a fast system, that was always "Done".
The system has been changed to retain all filter status messages in the file, and to display them all on the page. No status messages should be lost, no matter the speed of the system being tested.
Thanks for looking into it (it's not like the exact messages would be really critical, but it was an indication of a progress - or of things getting stuck somewhere and at which point...) I got somehow lost in the related commits, so I guess I'll wait for the next snapshot to test this.