## 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)

## 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)

## 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)

…257060)

# Backport

This will backport the following commits from `main` to `9.3`:
- [[APM] Improve redirect with default date range guard
(#256887)](#256887)

<!--- Backport version: 9.6.6 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Alex
Fernandez","email":"47327793+AlejandroFrndz@users.noreply.github.com"},"sourceCommit":{"committedDate":"2026-03-11T09:14:36Z","message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55","branchLabelMapping":{"^v9.4.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","backport:all-open","v9.4.0","Team:obs-presentation"],"title":"[APM]
Improve redirect with default date range
guard","number":256887,"url":"https://github.com/elastic/kibana/pull/256887","mergeCommit":{"message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.4.0","branchLabelMappingKey":"^v9.4.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/256887","number":256887,"mergeCommit":{"message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55"}}]}]
BACKPORT-->

Co-authored-by: Alex Fernandez <47327793+AlejandroFrndz@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

…257059)

# Backport

This will backport the following commits from `main` to `9.2`:
- [[APM] Improve redirect with default date range guard
(#256887)](#256887)

<!--- Backport version: 9.6.6 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Alex
Fernandez","email":"47327793+AlejandroFrndz@users.noreply.github.com"},"sourceCommit":{"committedDate":"2026-03-11T09:14:36Z","message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55","branchLabelMapping":{"^v9.4.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","backport:all-open","v9.4.0","Team:obs-presentation"],"title":"[APM]
Improve redirect with default date range
guard","number":256887,"url":"https://github.com/elastic/kibana/pull/256887","mergeCommit":{"message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.4.0","branchLabelMappingKey":"^v9.4.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/256887","number":256887,"mergeCommit":{"message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55"}}]}]
BACKPORT-->

Co-authored-by: Alex Fernandez <47327793+AlejandroFrndz@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

…#257058)

# Backport

This will backport the following commits from `main` to `8.19`:
- [[APM] Improve redirect with default date range guard
(#256887)](#256887)

<!--- Backport version: 9.6.6 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Alex
Fernandez","email":"47327793+AlejandroFrndz@users.noreply.github.com"},"sourceCommit":{"committedDate":"2026-03-11T09:14:36Z","message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55","branchLabelMapping":{"^v9.4.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","backport:all-open","v9.4.0","Team:obs-presentation"],"title":"[APM]
Improve redirect with default date range
guard","number":256887,"url":"https://github.com/elastic/kibana/pull/256887","mergeCommit":{"message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.4.0","branchLabelMappingKey":"^v9.4.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/256887","number":256887,"mergeCommit":{"message":"[APM]
Improve redirect with default date range guard (#256887)\n\n##
Summary\n\nCloses #256735\n\nThis PR updates the
RedirectWithDefaultDateRange guard in APM to improve\nhow we handle
invalid and unexpected values in time range parameters for\nURLs in APM
that require said parameters.\n\n## Root cause\n\nA fair amount of
routes in APM require a time range to be defined in the\nquery params of
the url. Without them, the components rendered within\nthis routes
wouldn't work properly and would instead throw errors that\nwould lead
to a page crash. To avoid crashing because of this, the APM\napp route
has a built in guard in one of the wrapping
components\n`RedirectWithDefaultDateRange`. This component runs some
validations\ninternally to verify that the time range parameters
(`rangeFrom` and\n`rangeTo`) are set. If any of the params are detected
missing, the\ncomponent stops the rendering tree (returns `null`) and
performs a\nredirect ensuring the both parameters are set with defaults
values in\ncase they're missing.\n\nWhile this approach ensures a time
range is set in case it is missing,\nit wasn't factoring in that the
parameters could be present but have\ninvalid values. Because up until
now we were just checking that range\nparameters had a string value, but
weren't validating the string\ncontent, the guard would allow rendering
to continue but the unparseable\nvalue would still trigger an error in
the components downstream, leading\nto a page crash.\n\nThe changes
introduced in this PR update the validation run in the guard\ncomponent
to verify not only that the parameters are set but also that\ntheir
values are valid, parseable datemath expressions. If one of them\n(or
both) aren't parseable, the redirect will be performed setting them\nto
whatever the default value for them should be. This ensures that
a\nvalid time range is always available for components that expect it,
both\nwhen the range is missing or when it is present but invalid\n\n##
Reproduction\nNavigate to the following
path\n`app/apm/services?comparisonEnabled=true&environment=ENVIRONMENT_ALL&rangeFrom=invalid&rangeTo=invalid&offset=1d`\nverify
how the page doesn't crash and the `rangeFrom` and `rangeTo`\nvalues are
replaced with valid default values. Defaults depend on kibana\nsettings,
but the standard defaults are `rangeFrom=now-15m&rangeTo=now`\n\n\n##
Release note\n\nFixes an issue in APM apps where the website would crash
if invalid\nvalues were passed to rangeFrom and rangeTo query parameters
in the URLs\n\n---------\n\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"58d20028eb3f533d507033ec2819a654a2a11a55"}}]}]
BACKPORT-->

Co-authored-by: Alex Fernandez <47327793+AlejandroFrndz@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

…e_fix

* commit '565f7545c422192218b803874fbdf93e8d8f08ee': (27 commits)
  [Lens API] ESQL schema for XY separately for Agent and some small token optimizations (elastic#256885)
  Fix "Accessing resource attributes before async attributes settled" telemetry error (elastic#256880)
  [Security Solution][Attacks/Alerts][Attacks page][Table section] Preserver "Sort by" state on Attacks page (elastic#256717) (elastic#256795)
  [APM] Improve redirect with default date range guard (elastic#256887)
  [Security Solution][Attacks/Alerts][Attacks page][Table section] Add assignees avatars to the group component (elastic#250126) (elastic#256901)
  [Docs] add xpack.alerting.rules.maxScheduledPerMinute setting description (elastic#257041)
  [SO] Fix non-deterministic ordering in nested find API integration tests (elastic#256447)
  [Write-restricted dashboards] Update user profile retrieval for getShouldAddAccessControl (elastic#255065)
  [One Workflow] Add Scout API test scaffold and execution tests (elastic#256300)
  [Fleet] add use_apm if dynamic_signal_types are enabled (elastic#256429)
  [Fleet] ignore data streams starting with `.` in Fleet API (elastic#256625)
  [ES|QL] METRICS_INFO support: columns_after & summary (elastic#256758)
  [Agent Builder] Agent plugins: initial installation support (elastic#256478)
  [Streams] Add field descriptions and documentation-only field overrides (elastic#255136)
  [api-docs] 2026-03-11 Daily api_docs build (elastic#257023)
  [Security Solution] fix alerts page infinite loading state due to data view error (elastic#256983)
  [Logging] Add `service.*` global fields (elastic#256878)
  [Canvas] Apply embeddable transforms to embeddable elements (elastic#252191)
  [table_list_view_table] stabilize jest test (elastic#254991)
  [Obs AI] get_index_info: add unit tests (elastic#256802)
  ...

## Summary

Closes #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>