Semantic convention around retry attempts?

[toumorokoshi]

What are you trying to achieve?

Propose a convention around retry count, if one does not exist already.

What did you expect to see?

A semantic convention around retry attempts. Motivated by open-telemetry/opentelemetry-python-contrib#275 (comment).

As a proposal:

• field name: retry_count
• value: integer
• description: the attempt number of retries for this particular request. 0 implies this is the first try, while 1 implies it is the first retry.

[anuraaga]

Having a retry convention would be great. One thing to compare against is using events to model retries to include timing. Just a count itself is pretty useful but this could be more complete and even more useful.

[pc-alves]

In the past I have used a combination of a Span Tag and Span Log:

• retry | bool | When present on a client span, they represent a span that wraps a retried RPC. If missing no interpretation can be made. An explicit value of false would explicitly mean it is a first RPC attempt.
• retry_number | integer | In combination with retry tag, this field holds the number of the retry attempt
  • (this one was set as a Span Log)

This allowed querying for retried calls, and knowing how many retries were done.

[aaron-ai]

'attempt' or 'attempt_times' may be better, 'retry_count' is ambiguous in my opinion.