Link to trace no longer working if trace occurred more than 15 minutes ago after upgrade from 7.12.1 to 7.15.0

Kibana version:
7.15.0

Elasticsearch version:
7.15.0

APM Server version:
7.15.0

APM Agent language and version:
OpenTelemetry Java Agent

Browser version:
OSX Chrome 93.0.4577.82

Original install method (e.g. download page, yum, deb, from source, etc.) and version:
Docker

Fresh install or upgraded from other version?
Upgrade from 7.12.1 to 7.15.0

Is there anything special in your setup? N/A

Description of the problem including expected versus actual behavior. Please include screenshots (if relevant):

In the past I've configured trace.id field as a URL based field so that in Discover views I can easily link off to trace data in APM. I have used the URL template - apm#/link-to/trace/{{value}} - which then generates links such as https://{{kibana}}/app/apm#/link-to/trace/{{trace.id}}

In 7.12.1 this worked correctly i.e. I could dig up old traces and have the link set the time range correctly on the lookup etc. Now in 7.15.0 I've noticed if I try to link to a trace that is older than 15 minutes:

  1. It pulls up the transactions view but the trace is not the correct one
  2. The date range defaults to the last 15 minutes which I don't think it did before although if I scale it back to say 7 days (or however far back the trace was) it doesn't matter as the direct has already occurred and the link appears to be pointing at the wrong trace.

If I open a trace that is less than 15 minutes ago it works correctly. So, I suspect something is happening here where it's pushing the time range down into the lookup and failing? Possibly related to the change/comment here as I see it added a default for 15 min - now.

I can see this in the direct, for instance:

5 minute old trace (works):
Original link: http://{{kibana}}/app/apm#/link-to/trace/61673c7c4da9b17df3a03aeb5d67c3fd

Redirected link: http://{{kibana}}/app/apm/services/{{service}}/transactions/view?transactionName={{transactionName}}&transactionType=request&rangeFrom=now-15m&rangeTo=now&comparisonEnabled=true&comparisonType=day&transactionId=abd1bcb03ea760f4&traceId=61673c7c4da9b17df3a03aeb5d67c3fd

Notice both URLs have 61673c7c4da9b17df3a03aeb5d67c3fd for the trace ID.

30 minute old trace (broken):
Original link: http://{{kibana}}/app/apm#/link-to/trace/616735962f42755bc4a6fe934949c28c

Redirected link: http://{{kibana}}/app/apm/services/{{service}}/transactions/view?transactionName={{omit_transactionName}}&transactionType=request&rangeFrom=now-15m&rangeTo=now&comparisonEnabled=true&comparisonType=day&transactionId=70bd2ada757f2988&traceId=616738e4c8ff6e7e5ffec75088b8f7a6

So the "traceId" parameter is 616735962f42755bc4a6fe934949c28c originally but 616738e4c8ff6e7e5ffec75088b8f7a6 on the redirect.

I also tried without the hash in the URL and it had the same issue.

Steps to reproduce:

  1. Find a trace that's over 15 minutes old and try to link directly to it (broken)
  2. Find a trace that's less than 15 minutes old and link to it (works)

Maybe a related issue here but this looks like it was fixed in 7.10 already so maybe some sort of regression although the behavior isn't that it errors right now, it just doesn't pull up the right data.

I can hack around this by passing rangeFrom=now-7d - it will work then for traces up to 7 days ago (which is good enough as a workaround for now) i.e. I've updated the field URL template to:

apm#/link-to/trace/{{value}}?rangeFrom=now-7d

But I am pretty sure this issue stems from the defaults on rangeFrom/rangeTo and that the logic here gives precedence to the input rangeFrom over the transaction data.

I'll log a github issue.

Logged an issue with Kibana github here

Thanks for opening a bug @rrupp_mgp! Looks like an easy fix, but want to make sure there are no unintended consequences. I'll look into it.