[APM] Abort browser requests when appropriate#89557
[APM] Abort browser requests when appropriate#89557dgieselaar merged 7 commits intoelastic:masterfrom
Conversation
|
Pinging @elastic/uptime (Team:uptime) |
|
Pinging @elastic/apm-ui (Team:apm) |
justinkambic
left a comment
There was a problem hiding this comment.
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.
| ); | ||
| } | ||
|
|
||
| const createLifecycleManagedCallApmApi = ( |
There was a problem hiding this comment.
nit (suggestion)
| const createLifecycleManagedCallApmApi = ( | |
| const createAbortableApmApiClient = ( |
There was a problem hiding this comment.
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.
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.
Agreed, let me think about it, I think that's one better at least.
|
|
||
| const createLifecycleManagedCallApmApi = ( | ||
| signal: AbortSignal | ||
| ): LifecycleManagedAPMClient => { |
There was a problem hiding this comment.
| ): LifecycleManagedAPMClient => { | |
| ): AbortableAPMClient => { |
|
|
||
| export function useFetcher<TReturn>( | ||
| fn: (callApmApi: APMClient) => TReturn, | ||
| fn: (callApmApi: LifecycleManagedAPMClient) => TReturn, |
There was a problem hiding this comment.
| fn: (callApmApi: LifecycleManagedAPMClient) => TReturn, | |
| fn: (apmApiClient: AbortableAPMClient) => TReturn, |
|
|
||
| return () => { | ||
| didCancel = true; | ||
| controller.abort(); |
There was a problem hiding this comment.
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.
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.
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.
We might not need the first one. But the second one we do, as the promise will be rejected when the request is aborted.
| export type APMClient = Client<APMAPI['_S']>; | ||
| export type LifecycleManagedAPMClient = Client< | ||
| APMAPI['_S'], | ||
| { lifecycleManaged: true } |
There was a problem hiding this comment.
| { lifecycleManaged: true } | |
| { isAbortable: true } |
sorenlouv
left a comment
There was a problem hiding this comment.
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 <42973632+kibanamachine@users.noreply.github.com>
…-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.