When I changed the system to recompile on request, some errors stopped showing up on the browser because we didn't return a page able to fetch those errors from the WebSocket. This is the first thing I fixed.
Since pages are recompiled on request, if there's an error in a page that's not the current page, you would have to navigate to that page in order to recompile and clear the error. That's not ideal, and I changed it so when an error is displayed to the user, it's cleared from the cache. If the user recompiles the page and the error still exists, it will be added again.
Finally, I've noticed a while ago that when there's an error in the compilation, the CI doesn't fail. This is happening because the failure stops the processing but doesn't return an error code different from 0. This is an issue in the VM itself and I solved it by changing it to System.halt.
gabrielpoca
commented
3 years ago
When I changed the system to recompile on request, some errors stopped showing up on the browser because we didn't return a page able to fetch those errors from the WebSocket. This is the first thing I fixed.
Since pages are recompiled on request, if there's an error in a page that's not the current page, you would have to navigate to that page in order to recompile and clear the error. That's not ideal, and I changed it so when an error is displayed to the user, it's cleared from the cache. If the user recompiles the page and the error still exists, it will be added again.
Finally, I've noticed a while ago that when there's an error in the compilation, the CI doesn't fail. This is happening because the failure stops the processing but doesn't return an error code different from 0. This is an issue in the VM itself and I solved it by changing it to System.halt.