-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[APM] Abort browser requests when appropriate #89557
Conversation
Pinging @elastic/uptime (Team:uptime) |
Pinging @elastic/apm-ui (Team:apm) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm rubber stamping this because it triggered a CODEOWNER review on one file. I'm operating under the assumption if signal: null
poses no threat to the rest of the routes changed it will operate similarly in the UX API.
@@ -39,6 +42,14 @@ function getDetailsFromErrorResponse(error: IHttpFetchError) { | |||
); | |||
} | |||
|
|||
const createLifecycleManagedCallApmApi = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit (suggestion)
const createLifecycleManagedCallApmApi = ( | |
const createAbortableApmApiClient = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered this, but every ApmApiClient's calls are abortable, if you pass a signal. This one takes care of aborting for you. So I'm not sure if createAbortableApmApiClient
is better here. But I agree that createLifecycleManagedCallApmApi
is not great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay. Would it make sense to call it createAutoAbortableApmClient
or something like that? "lifecycle" is pretty very vague, and not something I'd immediately associate with the request being aborted automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, let me think about it, I think that's one better at least.
@@ -39,6 +42,14 @@ function getDetailsFromErrorResponse(error: IHttpFetchError) { | |||
); | |||
} | |||
|
|||
const createLifecycleManagedCallApmApi = ( | |||
signal: AbortSignal | |||
): LifecycleManagedAPMClient => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
): LifecycleManagedAPMClient => { | |
): AbortableAPMClient => { |
@@ -48,7 +59,7 @@ type InferResponseType<TReturn> = Exclude<TReturn, undefined> extends Promise< | |||
: unknown; | |||
|
|||
export function useFetcher<TReturn>( | |||
fn: (callApmApi: APMClient) => TReturn, | |||
fn: (callApmApi: LifecycleManagedAPMClient) => TReturn, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fn: (callApmApi: LifecycleManagedAPMClient) => TReturn, | |
fn: (apmApiClient: AbortableAPMClient) => TReturn, |
@@ -130,7 +148,7 @@ export function useFetcher<TReturn>( | |||
doFetch(); | |||
|
|||
return () => { | |||
didCancel = true; | |||
controller.abort(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will the FETCH_STATUS
state be when a request is aborted? Should we introduce a new state or is that overkill (I'd rather not if we can avoid it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aborted is not necessarily a state here, it can be a result of a new request, the component unmounting, or the useFetcher cb not returning a promise. We were already "soft-canceling" requests before, so I don't think this change should affect state but I'll think about it for a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. I was trying to think through if we still needed the if (!signal.aborted) {
checks. Previously, if useFetcher props changed, we used didCancel = true
to avoid updating the state when the underlying request (which didn't get cancelled) returned.
Since we are now actually cancelling the request, will useFetcher still re-render upon cancellation (or some later stage) or can we omit the checks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might not need the first one. But the second one we do, as the promise will be rejected when the request is aborted.
@@ -12,11 +12,17 @@ import { APMAPI } from '../../../server/routes/create_apm_api'; | |||
import { Client } from '../../../server/routes/typings'; | |||
|
|||
export type APMClient = Client<APMAPI['_S']>; | |||
export type LifecycleManagedAPMClient = Client< | |||
APMAPI['_S'], | |||
{ lifecycleManaged: true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{ lifecycleManaged: true } | |
{ isAbortable: true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. Just on question around how cancellation affects re-rendering.
@elasticmachine merge upstream |
… into cancel-browser-request
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
Co-authored-by: Kibana Machine <[email protected]>
Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
…-ml-jobs * 'master' of github.com:elastic/kibana: (254 commits) [Security Solution] [Detections] Remove allow_no_indices to prevent error being thrown in response of field capabilities (elastic#89927) Skip test for cloud (elastic#89450) [Fleet] Fix duplicate data streams being shown in UI (elastic#89812) Bump package dependencies (elastic#90034) [App Search] DRY helper for encoding/decoding routes that can have special characters in params (elastic#89811) TypeScript project references for Observability plugin (elastic#89320) [SearchSource] Combine sort and parent fields when serializing (elastic#89808) Made imports static (elastic#89935) [ml] migrate file_data_visualizer/import route to file_upload plugin (elastic#89640) [Discover] Adapt default column behavior (elastic#89826) Round start and end values (elastic#89030) Rename getProxyAgents to getCustomAgents (elastic#89813) [Form lib] UseField `onError` listener (elastic#89895) [APM] use latency sum instead of avg for impact (elastic#89990) migrate more core-owned plugins to tsproject ref (elastic#89975) [Logs UI] Load <LogStream> entries via async searches (elastic#86899) [APM] Abort browser requests when appropriate (elastic#89557) [Alerting] Allow user to select existing connector of same type when fixing broken connector (elastic#89062) [Data Table] Use shared CSV export mechanism (elastic#89702) chore(NA): improve logic check when installing Bazel tools (elastic#89634) ...
Closes #81740.