Bugzilla

( Backlogging for bandwidth reasons. )

We discussed this in today's SDK meeting:
* Safe to backlog this as there's no immediate or external need as of yet
* Implementation possibilities
    * An HTTP header. Pros: We already have one (`X-Telemetry-Agent`) that kinda-sorta fits the bill. This is where information like this is "supposed" to go according to HTTP (e.g. `User-Agent`). The information rides with the ping upload that it describes. Cons: Not a metric, so harder to document and find and use (see also `Date` and `X-Telemetry-Agent` and friends).
    * A metric on the next ping of the same type. Pros: Is a metric (straightforward to add, use, discover). Cons: Is sent on the next ping (latency, incompleteness, difficult to join with affected ping)
    * A metric on the "metrics" ping. Pros: Is how we currently do [network health reporting](https://dictionary.telemetry.mozilla.org/apps/firefox_desktop?page=1&search=origin%3Aglean-core%20glean.upload), Is a metric. Cons: Is sent on a completely different ping (latency, hard to link to specific affected pings), not all applications send "metrics" pings (notably especially JS applications).
    * We rejected the idea of making it a ping on the current ping. After ping assembly on submit() the payload is treated as immutable. Upload happens after (sometimes long after) the ping payload was assembled. Trying to unwrap the payload and inject more information into it is a) icky, b) hard, c) possibly impossible if we change the payload format between submission and upload (ie if an SDK update happens).
* Additional related work
    * Recently we were asked how to determine which pings hadn't been able to be uploaded the first try or had been delayed on the client. The context was [Firefox Desktop's `spoc` ping](https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/pings/spoc), so it's not immediately relevant, but it's also asking about reporting network configuration and health reporting of pings. Satisfying this use case strongly suggests using HTTP headers to transmit the information (and internal metrics to store in the information), which lends more weight behind that potential design. But the request for information about retries has been satisfied, so this hasn't even been filed as a bug.
* We resolved to scope this bug narrowly and avoid implementing a full network health reporting system to satisfy the original request. This bug is about designing and implementing a solution for identifying the uploader in use in any given ping uploaded from Glean.js applications or other instrumentation to aid understanding how often different uploaders fail.

( Backlogging for bandwidth reasons. )

We discussed this in today's SDK meeting:
* Safe to backlog this as there's no immediate or external need as of yet
* Implementation possibilities
    * An HTTP header. Pros: We already have one (`X-Telemetry-Agent`) that kinda-sorta fits the bill. This is where information like this is "supposed" to go according to HTTP (e.g. `User-Agent`). The information rides with the ping upload that it describes. Cons: Not a metric, so harder to document and find and use (see also `Date` and `X-Telemetry-Agent` and friends).
    * A metric on the next ping of the same type. Pros: Is a metric (straightforward to add, use, discover). Cons: Is sent on the next ping (latency, incompleteness, difficult to join with affected ping)
    * A metric on the "metrics" ping. Pros: Is how we currently do [network health reporting](https://dictionary.telemetry.mozilla.org/apps/firefox_desktop?page=1&search=origin%3Aglean-core%20glean.upload), Is a metric. Cons: Is sent on a completely different ping (latency, hard to link to specific affected pings), not all applications send "metrics" pings (notably especially JS applications).
    * We rejected the idea of making it a metric on the current ping. After ping assembly on submit() the payload is treated as immutable. Upload happens after (sometimes long after) the ping payload was assembled. Trying to unwrap the payload and inject more information into it is a) icky, b) hard, c) possibly impossible if we change the payload format between submission and upload (ie if an SDK update happens).
* Additional related work
    * Recently we were asked how to determine which pings hadn't been able to be uploaded the first try or had been delayed on the client. The context was [Firefox Desktop's `spoc` ping](https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/pings/spoc), so it's not immediately relevant, but it's also asking about reporting network configuration and health reporting of pings. Satisfying this use case strongly suggests using HTTP headers to transmit the information (and internal metrics to store in the information), which lends more weight behind that potential design. But the request for information about retries has been satisfied, so this hasn't even been filed as a bug.
* We resolved to scope this bug narrowly and avoid implementing a full network health reporting system to satisfy the original request. This bug is about designing and implementing a solution for identifying the uploader in use in any given ping uploaded from Glean.js applications or other instrumentation to aid understanding how often different uploaders fail.

( Backlogging for bandwidth reasons. )

We discussed this in today's SDK meeting:
* Safe to backlog this as there's no immediate or external need as of yet
* Implementation possibilities
    * An HTTP header. Pros: We already have one (`X-Telemetry-Agent`) that kinda-sorta fits the bill. This is where information like this is "supposed" to go according to HTTP (e.g. `User-Agent`). The information rides with the ping upload that it describes. Cons: Not a metric, so harder to document and find and use (see also `Date` and `X-Telemetry-Agent` and friends).
    * A metric on the next ping of the same type. Pros: Is a metric (straightforward to add, use, discover). Cons: Is sent on the next ping (latency, incompleteness, difficult to join with affected ping)
    * A metric on the "metrics" ping. Pros: Is how we currently do [network health reporting](https://dictionary.telemetry.mozilla.org/apps/firefox_desktop?page=1&search=origin%3Aglean-core%20glean.upload), Is a metric. Cons: Is sent on a completely different ping (latency, hard to link to specific affected pings), not all applications send "metrics" pings (notably especially JS applications).
    * We rejected the idea of making it a metric on the current ping. After ping assembly on submit() the payload is treated as immutable. Upload happens after (sometimes long after) the ping payload was assembled. Trying to unwrap the payload and inject more information into it is a) icky, b) hard, c) possibly impossible if we change the payload format between submission and upload (ie if an SDK update happens).
* Additional related work
    * Recently we were asked how to determine which pings hadn't been able to be uploaded the first try or had been delayed on the client. The context was [Firefox Desktop's `spoc` ping](https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/pings/spoc), so it's not immediately relevant, but it's also asking about reporting network configuration and upload health. Satisfying this use case strongly suggests using HTTP headers to transmit the information (and internal metrics to store in the information), which lends more weight behind that potential design. But the request for information about retries has been satisfied, so this hasn't even been filed as a bug.
* We resolved to scope this bug narrowly and avoid implementing a full network health reporting system to satisfy the original request. This bug is about designing and implementing a solution for identifying the uploader in use in any given ping uploaded from Glean.js applications or other instrumentation to aid understanding how often different uploaders fail.