Before we get the bigger Lab release out I thought to collect the workaround step on these “stuck” cases in one place. These all have to do with environment building behind the Lab. These are not too common but common enough to warrant a post collecting all in one place.
Note: Most of these also affect the VsCode developers using Robocorp Code, but because VsCode is more an editor you can still write stuff without the environment which means users do not hit these problems as often whereas for Robocorp Lab the environment must be there so we can run the Jupyter Lab IDE.
- When opening a robot in Robocorp Lab the loading window gets stuck
- When starting Lab for the first time or after an update the initialization step fails with error GEN_0
The main culprits at play seem to be:
- Network proxy/firewall setups blocking access to load items needed in environment setups
- Virus scanning blocking file access or causing Windows file locks.
- Collisions or version mismatches in dependencies
- Some cases also have been caused by really bad internet connections where the retries we have in place are not enough.
This is pretty much out of our hands and usually, you need to contact your IT people.
Limiting outgoing traffic is not that common but still common enough in corporate settings that we have Firewall and network proxy requirements written out.
This is a tricky one and to disable or add exclusion to virus-scanning must always be done with permission from your IT / you have to know the risks involved.
Most development environments these days deal with a ton of dependencies which in turn means tons of small files must be copied to your machine at some point.
In Python and Node.js it is quite normal that even a basic environment consists of 10000 - 30000 files and a takes up few hundred to megabytes in size.
This of course poses a challenge to virus-scanner both in resources used to scan and detecting actually malicious stuff.
If you do run into actual virus-scanner hits (i.e. scanner reporting and quarantining files) we would appreciate reports where you list the scanner software and what the scanner reported.
For us, it is not possible to verify everything beforehand because the robot projects also contain code and libraries made by the community and yourself, so this goes back to dependency management. We can and do test the Lab application itself with virus scanners and the only hits that have been reported are cases where corporate virus-scanner blocks all executables that are not white-listed. We are tracking down one case with Mac virus scanning as well.
With these disclaimers out of the way, we have written up a guide on adding exceptions to Windows Defender purely for the case where you are willing to take the risk to get more speed.
For actual hits or corporate scanners not allowing things to run you again have to be in contact with your IT.
This one can be the hardest to detect and resolve and this is one of the main reasons why we are developing RCC toolchain.
Adding dependencies that internally require others with specific versions and those colliding is something that even we are not immune to (see Lab release 4.12.6 :).
We are trying to dig up these errors from the outputs of tools into detectable and understandable form but let’s just say it ain’t easy
If you added something to your conda.yaml and the robot opening now get this error check the conda.yaml content and try pinning down versions. We have new stuff on the way in RCC to help out with this.
…is to clear the cached files which means the environment gets a fresh try to load all the files and get everything in place.
This can be done with one RCC command.
…and in the case of Robocorp Lab, you don’t need to separately get the RCC tool as one comes with Lab. So the cleanup on Windows would be
%localappdata%\Programs\robocode-lab\build\rcc\rcc env cleanup --all
…and the nuclear option of course is to uninstall and re-install Lab, but we are doing our best to avoid this option.