I recently noticed a bug which should be easy to fix: https://treeherder.mozilla.org/#/jobs?repo=try&tier=1%2C2%2C3&revision=0843627ff611360c0c5bfa868525227293b16a74&selectedJob=288269853

In the raptor unittest, we have no_conditioned_profile set to False when it should be True. But a better way to solve this would be to have the os.makedirs take exists_ok=True as an argument so we don't have to do these workarounds (but maybe that's only available for python3?). The code for this is here: https://dxr.mozilla.org/mozilla-central/source/testing/condprofile/condprof/client.py?q=testing%2Fcondprofile%2Fcondprof%2Fclient.py&redirect_type=direct#75

It's a little odd though how it checks if the path exists first, and then proceeds to make it anyway so that might be another issue.

That is strange. Why does the call to os.path.exists() return False when it actually exists? Do we make use of multiple processes/threads when executing this code? Tarek, any idea?

Also we should wait with making it a mentored bug until the underlying issue is clear.

yeah exists_ok=True is Python 3 only and we want to keep client.py py2 compatible for raptor (until raptor switches)

Do we make use of multiple processes/threads when executing this code?

no, unless raptor itself does? but maybe the same VM is used by other jobs at the same time ? one thing we could do to see if this is the issue is to ignore that error and see if we get other race conditions later in the process

Yes, Raptor makes use of threading for the control server, but I fail to see how this could be related given that only the above code creates this directory: https://searchfox.org/mozilla-central/search?q=threading&path=raptor

We run all the tests in docker for Linux, which basically should isolate each job from others. But not sure if there is some magic we do. Joel, do you know of something?

my understanding is we only run a single job on a single instance. The only exception I know about is android emulators where we run multiple docker containers on a single host.

When checking some documentation about this method and other posts on the internet a lot of people also mention that this method can return false if the permission of the folder is not correct, so that os.stat() will fail. It actually masks the error, and returns False. For a better understanding os.stat(filename) could be used directly.

Greg, how often is that failure visible? Is it reproducible?

Very rarely, I've only seen this failure twice.

Greg, does that issue still exist? It has been classified the last time two months ago.

This patch disables conditioned-profiles in the cpu raptor tests - we have no need for conditioned profiles in this unittest.

I saw it recently, I've made a simple fix for it - we don't need conditioned profiles in the cpu tests.

https://hg.mozilla.org/mozilla-central/rev/e98059bbbc24