Add a "stack" parameter to the structured logging api

RESOLVED FIXED in mozilla33

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: chmanchester, Assigned: chmanchester)

Tracking

unspecified
mozilla33
x86_64
Linux
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

4 years ago
I'd like to use it in gaia unit tests for logging stacks.
(Assignee)

Comment 1

4 years ago
Created attachment 8453042 [details] [diff] [review]
Add an "extra" parameter for structured logging's test_status.
Attachment #8453042 - Flags: review?(james)
(Assignee)

Updated

4 years ago
Assignee: nobody → cmanchester
Status: NEW → ASSIGNED
What's the point of an 'extra' key? Whatever consumes it needs to have special knowledge of what it contains anyway, so why not just put 'extra' keys directly on the structured log object?
Actually I think it would be handy for all of the structured log methods to handle arbitrary kwargs.
The point of "extra" is that it cleanly separates the "standard" things from the non-standard, per-testsuite, things.

I would be strongly opposed to adding support for arbitary kwargs because it will make it very difficult to tell what's part of the core protocol that any consumers can depend on, and what's part of extensions that are only recognised by specific producers and consumers.

FWIW I'm not sure that it doesn't make sense to make the stack an optional top-level item on test_end and test_status, or something. It certainly seems like other suites might well have the concept of a stack that can be associated with a test result (it also seems like this isn't really needed for marionette; you could just reformat the message to fit the requirements of tbpl putting the summary on the first line and the full traceback on subsequent lines).
(Assignee)

Comment 5

4 years ago
(In reply to James Graham [:jgraham] from comment #4)
> The point of "extra" is that it cleanly separates the "standard" things from
> the non-standard, per-testsuite, things.
> 
> I would be strongly opposed to adding support for arbitary kwargs because it
> will make it very difficult to tell what's part of the core protocol that
> any consumers can depend on, and what's part of extensions that are only
> recognised by specific producers and consumers.
> 
> FWIW I'm not sure that it doesn't make sense to make the stack an optional
> top-level item on test_end and test_status, or something. It certainly seems
> like other suites might well have the concept of a stack that can be
> associated with a test result (it also seems like this isn't really needed
> for marionette; you could just reformat the message to fit the requirements
> of tbpl putting the summary on the first line and the full traceback on
> subsequent lines).

Agreed on a stack parameter, I'll make a patch. We care a lot about logs for tracking down errors/failures, and often the most useful part is the stack, so seperate treatment may be warranted. At least xpcshell as well will make good use of this api.

This is for gaia-unit-tests, not based on the marionette harness. I have a structured-logger translation of this reporter: https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-unit-tests/gaia_unit_test/reporters/tbpl.py , which logs stacks at a test_status-like moment.
(Assignee)

Comment 6

4 years ago
Created attachment 8453073 [details] [diff] [review]
Add a parameter to the structured log api for stacks in test_status and test_end.

I have no interest in extending the api for each suite-specific piece of data we encounter, but I think stacks warrant special treatment.
Attachment #8453073 - Flags: review?(james)
(Assignee)

Updated

4 years ago
Attachment #8453042 - Attachment is obsolete: true
Attachment #8453042 - Flags: review?(james)
(Assignee)

Updated

4 years ago
Summary: Add an "extra" parameter to the structured logger's test_status method → Add a "stack" parameter to the structured logging api
Comment on attachment 8453073 [details] [diff] [review]
Add a parameter to the structured log api for stacks in test_status and test_end.

Review of attachment 8453073 [details] [diff] [review]:
-----------------------------------------------------------------

This looks fine. Did any of the other versions of structured logging land (e.g. the js version)? If so we should probably update it there as well.
Attachment #8453073 - Flags: review?(james) → review+
(Assignee)

Comment 8

4 years ago
(In reply to James Graham [:jgraham] from comment #7)
> Comment on attachment 8453073 [details] [diff] [review]
> Add a parameter to the structured log api for stacks in test_status and
> test_end.
> 
> Review of attachment 8453073 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This looks fine. Did any of the other versions of structured logging land
> (e.g. the js version)? If so we should probably update it there as well.

Great, thanks! Not landed, I'll update along with the xpcshell patch.
(In reply to James Graham [:jgraham] from comment #4)
> The point of "extra" is that it cleanly separates the "standard" things from
> the non-standard, per-testsuite, things.

I don't really see why the distinction is important. If someone is wondering what they can depend on, that's what docs are for. But sure.

Either way, if we special case stack, be prepared to also special case things like memory leaks.
(In reply to Andrew Halberstadt [:ahal] from comment #9)

> Either way, if we special case stack, be prepared to also special case
> things like memory leaks.

Sure, I think that's fine. If there are things that are generally applicable, having well-known ways of handling them is good. I'm just trying to avoid a free-for-all where every consumer ends up tightly coupled to a small set of producers whose data it understands.

I wonder if this has any impact on the right thing to do in bug 1023371 which adds a top-level "crash" field, that doesn't have a "stack" parameter per-se. For example it could reuse the stack parameter for the stack info and print the rest of the data in a seperate message. Or we could s/stack/crash/ here and have the value be an object with at least a stack parameter and some optional parameters.
I guess that depends.. does stack here strictly refer to a crash stack? What about an exception stack?
https://hg.mozilla.org/mozilla-central/rev/6a05955e2dc0
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.