And as a user, having https://tbpl.mozilla.org/leak-analysis/?id=7199799&tree=Mozilla-Inbound tell me "Could not find log file in cache for id: 7199799" doesn't tell me a single thing I want to know. Can't find it? Go fetch it! No clue why it wouldn't be there, either - I'd already loaded the scrape and the summary long before I hit that link, so I'd think we must have fetched the log.
I can't really remember the last time it actually worked.
Interesting that it never works at all on tbpl.m.o, and works perfectly on tbpl.swatinem.de. Since that's quite a few revs back right now, can't really tell whether that means that we broke it sometime between whatever it's updated to and the tip, or just means that something in the setup of tbpl.m.o is breaking it.
Summary: "Analyze the leak" frequently fails with "Could not find log file in cache for id: ..." → "Analyze the leak" always fails with "Could not find log file in cache for id: ..." on tbpl.m.o
I’ve recently updated my server to 962932eba448 (+ qseries), so it’s not that far back.
(In reply to Arpad Borsos (Swatinem) from comment #3) > I’ve recently updated my server to 962932eba448 (+ qseries), so it’s not > that far back. Was it that upgrade, or the patch for bug 717005, which completely broke this on your server as well?
Severity: critical → blocker
(In reply to Phil Ringnalda (:philor) from comment #4) > (In reply to Arpad Borsos (Swatinem) from comment #3) > > I’ve recently updated my server to 962932eba448 (+ qseries), so it’s not > > that far back. > > Was it that upgrade, or the patch for bug 717005, which completely broke > this on your server as well? Yes definitely bug 717005, the leak analysis php script is different from all the others. Time to refactor it. The problem is that it still has usetinderbox fallback mode which makes it a bit harder. When can we get rid of that altogether?
From leak-analysis? Right now. The only Firefox-related things still using tinderbox are SpiderMonkey shell builds and Jetpack, neither of which would know a domwindow if it leaked into their shoe, and the mozillamessaging version of tbpl is probably very nearly a completely separate fork by now.
I think the cause for this bug is the same as in bug 717005. The leak-analysis script expects the raw log to be present (without downloading it itself). The assumption is that once the UI presents a leak-analysis link, the raw log would already be present in the filesystem. This is not the case once the UI is updated based on a request served by server 1 (with a cached raw log), but server 2 (without a cached log) is used to serve leak-analysis.
Fixed, per bug 717005 comment 49.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.