feat(rack): add public_request config option

[hwu1001]

From this post #1985

For some endpoints with a public ingress there may be a traceparent header on the incoming request, but the request's parent trace originates from somewhere that will never be ingested in the receiving system. The result for the receiving system is that when they store their trace in a backend the parent trace will never be found so the parent trace name could be ambiguous or other effects depending on the backend.

As a reference to another language SDK, Go's otelhttp package has a WithPublicEndpointFn option that has the following in the docs:

WithPublicEndpointFn runs with every request, and allows conditionally configuring the Handler to link the span with an incoming span context. If this option is not provided or returns false, then the association is a child association instead of a link.

This change adds a new configuration option for the rack instrumentation called public_request that mirrors the behavior in the Go SDK above. By default, this option has the same behavior the rack instrumentation has currently, which is to create a child association to the incoming span. I called the option public_request instead of something like public_endpoint because the configuration runs for each request and a given endpoint may be used publicly and privately, but it depends on the request to determine whether it's one or the other. I didn't see a previous example of documenting an option for a callable so added some information that also mirrors the Go otelhttp SDK, but can update that to match what's expected from the maintainers.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: hwu1001 / name: Henry Wu (c331394)

[xuan-cao-swi]

Does the option have to be callable? From the test case, it seems only testing true/false (most time options tend to avoid use callable).

[hwu1001]

I was thinking that in some cases the endpoint might have both public and private ingress so based on some headers or other information from the request the configuration could determine how to create the span.

[xuan-cao-swi]

In that case, I am thinking maybe it's better to have an array that include list of allowing public_request e.g. untraced_hosts

[hwu1001]

Not sure I follow, would the array have a list of where the request originated from or a list of endpoints to determine how to create the span?

In case it helps - to add the use case I was thinking before is that for different Rack applications they might configure what is considered a public vs. private request on the URL path, headers, or other request information so having the callable seemed the most flexible way to meet the various ways the public/private distinction could come up. Is the concern with the callable that it's more difficult to configure?

[xuan-cao-swi]

Yes, that's the only concern since callable gives too much freedom.
Although, it doesn't mean it can't be callable.
Could you add more test case where shows the callable is necessary.

[thompson-tomo]

I am wondering if this is not something we should be raising at the spec level for a consistent experience.

The nicest solution for me is if we could have a remoteContextAnalyzer which is triggered when creating a span. The analyzer would decide based on context & attributes if it should be a parent, link or dropped.

This would enable all instrumentation to benefit etc.