Handle "not modified" errors properly #120

jhump · 2023-07-05T22:37:19Z

A "not modified" error really should not be counted as an error with "Unknown" error code. So this addresses that.

That does beg the question: how should it be handled? I see three options:

Skip the status code attribute entirely, since "not modified" doesn't cleanly map to an RPC code.
Treat it as "okay"/zero, since it's not really an error condition.
Don't use an RPC status code and instead use an HTTP status code attribute.

This PR currently uses the last option. But I'm happy to change it, based on what a larger group of minds thinks is the best way to label this state.

akshayjshah · 2023-07-06T04:32:34Z

Being compatible with gRPC's oddball status codes is one of the most painful parts of this project 😬 I wish we could add a status code specifically for 304s, but c'est la vie.

Effectively, I think that the approach proposed here is doing both 2 & 3 - it's not reporting an RPC error/status, and it's instead setting an HTTP status code. Overall, that seems right to me!

akshayjshah · 2023-07-06T04:39:35Z

attributes.go

+		// it would be misleading to label it as an unknown error since it's not really
+		// an error, but rather a sentinel to trigger a "304 Not Modified" HTTP status.
+		codeKey := attribute.Key("http.response.status_code")
+		return codeKey.Int(http.StatusNotModified), true


This seems right directionally. A few thoughts:

Suggest using semconv.HTTPStatusCode instead of hand-writing a string for the attr key. OTel is really larded up with standards, and I think the blessed key for this data is http.status_code - there's enough of this nonsense that we should just use the giant package of constants where possible.

Can we move this into the Connect-specific portion of the switch statement below? It makes sense to me that we treat this as an actual unknown error for the gRPC protocols, since that's how clients will interpret it. For the Connect protocol, it makes sense to omit the RPC error code and include an HTTP status code instead.

Hmm, that is weird that this constant uses http.status_code. According to the docs I found, it is http.response.status_code: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md#common-attributes

Anyhow, I'll change it to use the constant, and let otel fix either their docs or that constant if one of them is wrong 🤷

Oh, OTel.... 😭

akshayjshah · 2023-07-06T16:22:48Z

@jhump Please hold off on a release here; we also need to update spanStatus.

jhump · 2023-07-06T16:24:37Z

Oh, good catch. Sorry I missed that in this PR. I clearly don't know this repo very well.

akshayjshah · 2023-07-06T16:29:11Z

No worries - it's surprisingly complicated. I opened a PR to fix that issue, but I think we ought to add a test or two to make sure that the final telemetry output looks correct.

If the RPC is using the Connect protocol and returns a not modified error, we shouldn't set the span status to error. Follow-up to #120. --------- Co-authored-by: Josh Humphries <[email protected]>

For Connect RPCs that use GET and a "304 Not Modified" status is returned, the metric will use the `http.status_code` attribute with a value of 304, instead of an `rpc.connect.error_code` attribute. (It would previously label the metric with an error code of "unknown", which is misleading.)

If the RPC is using the Connect protocol and returns a not modified error, we shouldn't set the span status to error. Follow-up to #120. --------- Co-authored-by: Josh Humphries <[email protected]>

jhump added 2 commits July 5, 2023 18:32

carve out for 'not modified' sentinel error

5384341

update golangci-lint to work w/ go 1.20

bd41a9d

jhump requested review from joshcarp and akshayjshah July 5, 2023 22:37

akshayjshah requested changes Jul 6, 2023

View reviewed changes

review feedback

b87fe1f

akshayjshah approved these changes Jul 6, 2023

View reviewed changes

jhump merged commit 5403124 into main Jul 6, 2023

jhump deleted the jh/handle-not-modified-errors-properly branch July 6, 2023 16:08

akshayjshah mentioned this pull request Jul 6, 2023

Handle HTTP 304s when setting span status #121

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle "not modified" errors properly #120

Handle "not modified" errors properly #120

jhump commented Jul 5, 2023 •

edited

Loading

akshayjshah commented Jul 6, 2023

akshayjshah Jul 6, 2023 •

edited

Loading

jhump Jul 6, 2023

jhump Jul 6, 2023

akshayjshah Jul 6, 2023

akshayjshah commented Jul 6, 2023

jhump commented Jul 6, 2023

akshayjshah commented Jul 6, 2023

Handle "not modified" errors properly #120

Handle "not modified" errors properly #120

Conversation

jhump commented Jul 5, 2023 • edited Loading

akshayjshah commented Jul 6, 2023

akshayjshah Jul 6, 2023 • edited Loading

Choose a reason for hiding this comment

jhump Jul 6, 2023

Choose a reason for hiding this comment

jhump Jul 6, 2023

Choose a reason for hiding this comment

akshayjshah Jul 6, 2023

Choose a reason for hiding this comment

akshayjshah commented Jul 6, 2023

jhump commented Jul 6, 2023

akshayjshah commented Jul 6, 2023

jhump commented Jul 5, 2023 •

edited

Loading

akshayjshah Jul 6, 2023 •

edited

Loading