1900442 - TEST-UNEXPECTED-FAIL | path/to/test | A promise chain failed to handle a rejection: can't access property "set", Glean.crash.stackTraces is undefined - from resource://gre/modules/CrashManager.sys.mjs:815:9 when used against artifact builds

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect)

Description

[:Gijs (out for now; he/him)]

This is hitting very different sets of try pushes that use artifact builds, making them unusable.

cf. https://treeherder.mozilla.org/jobs?repo=try&revision=30b1290ba5c384e3d2ea8d8d262134507f171350&selectedTaskRun=U8n99mygRKeFAjsa-zsfcg.0

https://treeherder.mozilla.org/jobs?repo=try&revision=aea0ed23f771de241b8c346441cfa6036c412cd4&selectedTaskRun=QVxEobYOQnqKm4WK3HXMuA.0

etc.

The priority here would be to stop breaking all the artifact tests (i.e. by fixing the code so it doesn't throw), though a secondary thing that would be useful would be making it so this code (whatever is triggering it) caught its own exceptions and reported them more usefully (ideally still in a way that would cause at least some task to fail if something broke - but not all artifact browser chrome tests ever...).

Comment 1

[:Gijs (out for now; he/him)]

Alex, could you take a look please?

Comment 2

[Alex Franchuk [:afranchuk]]

Pardon my ignorance, but how do artifact builds work? More specifically, which code is downloaded as artifacts in this case, and how are incompatible versions normally handled (if that's a possibility at all)? Here we've added some new Glean metrics and are trying to set them. It's not clear to me how this case differs from anyone else doing the same (e.g., the last time I added new metrics) and causes an error to occur.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1815316

Comment 4

[:Gijs (out for now; he/him)]

(In reply to Alex Franchuk [:afranchuk] from comment #2)

Pardon my ignorance, but how do artifact builds work? More specifically, which code is downloaded as artifacts in this case,

All the binary bits. Everything apart from JS modules and frontend JS/CSS/image code, basically.

and how are incompatible versions normally handled (if that's a possibility at all)?

The code that downloads the artifacts and merges them into the source code bits of frontend code (post-processed if necessary) should be getting them from the correct revision, so they should be compatible. I don't think the issue in the tests on try is one of incompatible binaries - they're trypushes off central (probably) and artifacts for those central builds should be available and published.

Here we've added some new Glean metrics and are trying to set them. It's not clear to me how this case differs from anyone else doing the same (e.g., the last time I added new metrics) and causes an error to occur.

Me neither. Perhaps crash reporter is turned on/off somewhere else for artifact vs. binary builds? But then, presumably the glean metrics should be available either way?

302 chutten or Alessio to help redirect to people who would understand what the distinction here could be.

Comment 5

[Chris H-C :chutten]

Ah, object metrics aren't yet supported in the subsystem responsible for artefact build support see bug 1883857. The "correct" action in the meantime is to guard this access against it not being defined, perhaps through ?. operators and put a comment in so we can remove the guard when artefact builds become supported.

(Attn: Jan-Erik)

Comment 6

[Alex Franchuk [:afranchuk]]

chutten thanks for the info, I'll guard the use of object metrics (there are two more).

Comment 7

[Alex Franchuk [:afranchuk]]

Attachment: Bug 1900442 - Work around object metrics being unavailable in artifact builds r=chutten

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8d0161de02f4
Work around object metrics being unavailable in artifact builds r=chutten

Comment 9

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/8d0161de02f4