Skip to content

[9.2] [APM] Improve redirect with default date range guard (#256887)#257059

Merged
kibanamachine merged 1 commit intoelastic:9.2from
kibanamachine:backport/9.2/pr-256887
Mar 11, 2026
Merged

[9.2] [APM] Improve redirect with default date range guard (#256887)#257059
kibanamachine merged 1 commit intoelastic:9.2from
kibanamachine:backport/9.2/pr-256887

Conversation

@kibanamachine
Copy link
Copy Markdown
Contributor

Backport

This will backport the following commits from main to 9.2:

Questions ?

Please refer to the Backport tool documentation

## Summary

Closes elastic#256735

This PR updates the RedirectWithDefaultDateRange guard in APM to improve
how we handle invalid and unexpected values in time range parameters for
URLs in APM that require said parameters.

## Root cause

A fair amount of routes in APM require a time range to be defined in the
query params of the url. Without them, the components rendered within
this routes wouldn't work properly and would instead throw errors that
would lead to a page crash. To avoid crashing because of this, the APM
app route has a built in guard in one of the wrapping components
`RedirectWithDefaultDateRange`. This component runs some validations
internally to verify that the time range parameters (`rangeFrom` and
`rangeTo`) are set. If any of the params are detected missing, the
component stops the rendering tree (returns `null`) and performs a
redirect ensuring the both parameters are set with defaults values in
case they're missing.

While this approach ensures a time range is set in case it is missing,
it wasn't factoring in that the parameters could be present but have
invalid values. Because up until now we were just checking that range
parameters had a string value, but weren't validating the string
content, the guard would allow rendering to continue but the unparseable
value would still trigger an error in the components downstream, leading
to a page crash.

The changes introduced in this PR update the validation run in the guard
component to verify not only that the parameters are set but also that
their values are valid, parseable datemath expressions. If one of them
(or both) aren't parseable, the redirect will be performed setting them
to whatever the default value for them should be. This ensures that a
valid time range is always available for components that expect it, both
when the range is missing or when it is present but invalid

## Reproduction
Navigate to the following path
`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`
verify how the page doesn't crash and the `rangeFrom` and `rangeTo`
values are replaced with valid default values. Defaults depend on kibana
settings, but the standard defaults are `rangeFrom=now-15m&rangeTo=now`

## Release note

Fixes an issue in APM apps where the website would crash if invalid
values were passed to rangeFrom and rangeTo query parameters in the URLs

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
(cherry picked from commit 58d2002)
@kibanamachine kibanamachine added the backport This PR is a backport of another PR label Mar 11, 2026
@kibanamachine kibanamachine enabled auto-merge (squash) March 11, 2026 09:24
@botelastic botelastic bot added the Team:obs-presentation Focus: APM UI, Infra UI, Hosts UI, Universal Profiling, Obs Overview and left Navigation label Mar 11, 2026
@elasticmachine
Copy link
Copy Markdown
Contributor

Pinging @elastic/obs-presentation-team (Team:obs-presentation)

@kibanamachine kibanamachine merged commit bdd569f into elastic:9.2 Mar 11, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport This PR is a backport of another PR Team:obs-presentation Focus: APM UI, Infra UI, Hosts UI, Universal Profiling, Obs Overview and left Navigation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants