1742094 - "Received upload request" log isn't necessarily that useful.

Status: RESOLVED WONTFIX

(Data Platform and Tools :: Glean: SDK, task, P2)

Description

[Chris H-C :chutten]

The log in glean::net "Received upload task: <task>" prints the request's body.

The request's body is most often gzipped these days and so it ends up looking like this:

0:34.11 GECKO(1295411) [2021-11-19T13:53:26Z TRACE glean::net] Received upload task: Upload(PingRequest { document_id: "51de5e9a-0c10-457f-8d4f-ab431e51df47", path: "/submit/firefox-desktop/baseline/1/51de5e9a-0c10-457f-8d4f-ab431e51df47", body: [31, 139, 8, 0, 0, 0, 0, 0, 0, 255, 133, 82, 203, 114, 195, 32, 12, 252, 23, 206, 177, 7, 18, 219, 177, 253, 13, 61, 246, 206, 200, 160, 56, 76, 8, 118, 121, 164, 201, 100, 242, 239, 21, 121, 53, 109, 15, 5, 46, 136, 213, 106, 181, 226, 204, 102, 227, 70, 105, 220, 102, 98, 253, 153, 5, 252, 96, 61, 95, 176, 16, 193, 71, 25, 205, 30, 89, 207, 150, 124, 41, 10, 65, 167, 123, 231, 109, 95, 175, 10, 94, 247, 156, 179, 5, 67, 167, 255, 197, 120, 132, 48, 57, 66, 128, 138, 230, 128, 236, 178, 96, 202, 26, 116, 241, 89, 51, 162, 197, 61, 70, 127, 146, 65, 239, 228, 144, 140, 213, 4, 175, 150, 165, 40, 51, 193, 3, 157, 131, 170, 214, 131, 198, 161, 42, 58, 197, 135, 162, 106, 4, 47, 58, 93, 53, 69, 181, 6, 88, 173, 68, 3, 208, 46, 41, 101, 99, 124, 136, 210, 39, 39, 53, 196, 159, 234, 158, 186, 96, 158, 165, 218, 130, 115, 104, 9, 160, 113, 3, 201, 198, 123, 92, 155, 48, 91, 56, 201, 3, 250, 96, 174, 226, 187, 166, 228, 32, 242, 179, 87, 91, 19, 81, 197, 228, 51, 241, 177, 109, 100, 83, 81, 124, 10, 116, 123, 51, 46, 29, 175, 151, 151, 212, 186, 172, 238, 180, 143, 214, 178, 26, 90, 173, 88, 115, 218, 217, 145, 220, 190, 81, 33, 187, 145, 21, 223, 60, 61, 179, 209, 34, 184, 242, 0, 214, 80, 148, 216, 202, 239, 198, 182, 83, 242, 191, 109, 191, 247, 150, 29, 158, 146, 139, 232, 51, 199, 224, 167, 207, 128, 190, 68, 55, 194, 72, 62, 187, 88, 222, 38, 65, 147, 83, 59, 42, 41, 8, 111, 97, 160, 33, 104, 249, 146, 247, 167, 118, 254, 39, 65, 134, 52, 236, 77, 140, 168, 51, 230, 41, 91, 92, 104, 125, 1, 201, 24, 122, 105, 75, 2, 0, 0], headers: {"Content-Encoding": "gzip", "User-Agent": "Glean/42.1.0 (Rust on Linux)", "Content-Length": "342", "X-Client-Version": "42.1.0", "Date": "Fri, 19 Nov 2021 13:53:26 GMT", "X-Client-Type": "Glean", "Content-Type": "application/json; charset=utf-8"} })

...which isn't that helpful.

Now, this is a trace-level log so maybe the correct solution is to tell chutten not to log at trace. Maybe RUST_LOG="glean" should be replaced in chutten's muscle memory with RUST_LOG="glean=debug".

But then again, maybe there's something clever we could do here.

Comment 1

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Not too bad though:

; echo '[31, 139, ...]' | ruby -rzlib -e 'data=eval($stdin.read);puts Zlib::GzipReader.new(StringIO.new(data.map(&:chr).join(""))).read' | jq .
{
  "ping_info": {
    "seq": 0,
    "start_time": "2021-11-19T08:53-05:00",
    "end_time": "2021-11-19T08:53-05:00",
    "reason": "active"
  },
[...]

Not perfect either. I argue because it's trace though it's fine. Being smart there for a debugging thing seems like too much work (we'd need to manually inspect it, decode the gzip, or need to change the debug representation of PingRequest to do the ungzipping, but then it's not just a simple debug anymore).

I'm inclined to close this as wontfix.

Comment 2

[Chris H-C :chutten]

Since it's trace, could/should we ungzip it as we log? (Yeah, wontfix would be fine)

Comment 3

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

(In reply to Chris H-C :chutten from comment #2)

Since it's trace, could/should we ungzip it as we log? (Yeah, wontfix would be fine)

We could, but actually it should already be gunzipped-and-printed in glean-core