After adding some tests ( issue 572930 ), I found that the (locally) the insertMultipleOriginFramesAndImmediatelyRemoveFrames test in test_unload6.js fails quite often due to tabId being -1.

./browser_tests --gtest_filter=ExtensionWebRequestApiTest.WebRequestUnloadImmediately --

The test does the following:
1. Open new page at origin A and wait until it's loaded.
2. Insert a frame at origin A and another frame at origin B (different from A!!!).
3. Remove frame A and B (synchronously after the previous step).
4. Wait for two onErrorOccurred events, and check the result.

When the test fails, this happens:

[FAIL] insertMultipleOriginFramesAndImmediatelyRemoveFrames: API Test Error in insertMultipleOriginFramesAndImmediatelyRemoveFrames
Actual: [{"error":"net::ERR_ABORTED","frameId":1,"fromCache":false,"method":"GET","parentFrameId":0,"tabId":12,"type":"sub_frame"},{"error":"net::ERR_ABORTED","frameId":2,"fromCache":false,"method":"GET","parentFrameId":0,"tabId":-1,"type":"sub_frame"}]
Expected: [{"method":"GET","frameId":1,"parentFrameId":0,"tabId":12,"type":"sub_frame","fromCache":false,"error":"net::ERR_ABORTED"},{"method":"GET","frameId":2,"parentFrameId":0,"tabId":12,"type":"sub_frame","fromCache":false,"error":"net::ERR_ABORTED"}]

Often only the second tabId is -1; occasionally (rarely), even the first tabId is also -1.
This happens with and without --site-per-process.

And in the ~50 times that I ran the test locally, I found that the next test failed too (insertCrossOriginFrameAndImmediatelyRemoveFrame = insert 1 cross-origin frame and remove it).

In all cases, frameId and parentFrameId had meaningful values.

Devlin, this bug might be caused by the 0.15% failures to look up the data on the IO thread, per 1790e82aac659c28dfbd9aac82f1feb4a839f405. I'm going to address this by putting the tabId retrieval logic together with the frameId retrieval logic (where an optional thread hop may occur), you might want to investigate further why tabId is -1 at this point.