If compass is run with a fresh new user directory (in E2E tests that's firstRun: true), then one test fails: networkTraffic: false / Isolated Edition -> does not attempt to perform network I/O https://parsley.mongodb.com/test/10gen_compass_main_e2e_coverage_e2e_coverage_1_patch_[...]/60c9b8370d9d0c1f201e1e9511018487?bookmarks=0,3&shareLine=0

I have set firstRun: false in that file so it keeps working for now. I'm thinking something in the welcome modal (or maybe chromium?) is probably violating the setting.

update 2/12

 
COMPASS-8166: here's what I've tried so far, can I request an eng reviewer to say either "that all looks right to me" or "I think you missed some obvious stuff to try"? I thought this was about 3 points but I've sunk in about 4 days with little to show, so I think we basically need to reestimate the work and reprioritize.The bug is that isolated mode is making a network request. it looks to me like this is happening quite early, probably in the electron non-compass layer, for 3 reasons: # when I correlate strace with the electron logs via -tt flag, it looks like the error is happening like 2 seconds before compass logic happens, in particular before the electron warning gets logged that we disabled security stuff.

1. the error can be repro'ed with either firstRun: true or just by running only this test. it's not uncommon for e2e tests to be less than 100% isolated... but this implies to me it may be something more environmental than business logic-based since you can force the error just by changing the environ.
2. adding some logic to hijack the http, https request constructions and hijack session.webRequest.onBeforeRequest shows no logs. those techniques should be fairly thorough for a node process so something is happening pretty early.
3. also when you block network requests as a chromium option you wind up getting fewer but not none. idk if this is signficant.

Unfortunately it's pretty hard to debug this as we can't really run it in an environment we have control over. # macbook: no strace. and, since I can't even prove the error is happening except for strace, it's not like you can just run without strace and debug.

1. per las week's thread we don't yet have an evergreen/spruce ubuntu box working.
2. similarly I couldn't get docker/debian working although in principle this should be debuggable and possible.
3. Furthermore, this kind of makes it hard to do a PR binary search. The test/isolated feature is 3 years old so it's very hard to like, check out old code, hope nothing has changed about setting up evergreen in the last 3 years, unless you can just actually run it locally like normal.

Note one corollary of the above is we're not even 100% sure there really is a network request in isolated or if this is somehow a fragment of how we boot up electron in the e2e test.From here my thinking is: # Definitely make sure we can run this reasonably, in an environment we control. Tighter debug loop than CI runs is necessary.

1. from here next step would be write a "hello world!" electron app and run that on our e2e framework instead of compass and repro it. if repros it's some sort of webdriver/electron-y problem. if not then you bin search the compass app itself. (I tried dummying out welcome modals, doesn't help.)