Fix validation for duration vars on APM configuration settings#124336
Conversation
|
Pinging @elastic/apm-ui (Team:apm) |
|
Pinging @elastic/fleet (Team:Fleet) |
There was a problem hiding this comment.
could the type be more specific?
There was a problem hiding this comment.
you could try with this:
or you could create a meaningful type for the fixApmDurationVars method and cast it at the call site
There was a problem hiding this comment.
maybe there could be a check to only run this logic for apm package type
There was a problem hiding this comment.
Where I can check if it's an apm package type?
There was a problem hiding this comment.
here you can use basePackage: basePackage.name === 'apm'
There was a problem hiding this comment.
could you add unit tests for this logic?
|
I'm wondering if these vars could be fixed on the apm package definition itself, it doesn't look good to call a package specific logic in fleet code |
e6a40f1 to
cd1eaeb
Compare
💛 Build succeeded, but was flakyTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
|
is the flaky test related in any way to this change? |
|
The following labels were identified as gaps in your version labels and will be added automatically:
If any of these should not be on your pull request, please manually remove them. |
…ic#124336) * Fix validation for duration vars on apm configuration settings * Add unit test and just do the fix if the base package is apm (cherry picked from commit c51daa7)
💔 Some backports could not be created
How to fixRe-run the backport manually: Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…ic#124336) * Fix validation for duration vars on apm configuration settings * Add unit test and just do the fix if the base package is apm (cherry picked from commit c51daa7) # Conflicts: # x-pack/plugins/fleet/public/applications/fleet/sections/agent_policy/edit_package_policy_page/index.tsx
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
|
I could use some background on why this needed to change in the Fleet code rather than being handled in the APM policy UI or the migration from APM server -> integration policy code path. |
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
2 similar comments
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
| if ( | ||
| entry[0] === IDLE_TIMEOUT || | ||
| entry[0] === READ_TIMEOUT || | ||
| entry[0] === SHUTDOWN_TIMEOUT || | ||
| entry[0] === TAIL_SAMPLING_INTERVAL || | ||
| entry[0] === WRITE_TIMEOUT | ||
| ) { |
There was a problem hiding this comment.
@MiriamAparicio if you make DURATION_APM_SETTINGS_VARS an array you can simplify this to:
if (DURATION_APM_SETTINGS_VARS.includes(entry[0])) {|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
2 similar comments
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
The It's certainly possible to contain everything in the APM extension code without leaking into the fleet UI code, but we would essentially have to duplicate the 'staging area' pattern of that is already implemented in the fleet UI ( |

Closes #121640
Screen.Recording.2022-02-02.at.11.26.25.mov