I'm not sure that there is anything to do here? Sometimes requests time out. I suppose we could present a message to the user that this is happening with a prompt to retry the request (the request is to fetch suggested edits tasks, usually) and not log the error? @RHo what do you think?

In T295670#7926700, @kostajh wrote:

I'm not sure that there is anything to do here? Sometimes requests time out. I suppose we could present a message to the user that this is happening with a prompt to retry the request (the request is to fetch suggested edits tasks, usually) and not log the error? @RHo what do you think?

I might need a little more context but I'm firstly curious if we know on average how long before it times out? If it was 20-30sec then an error message and retry action definitely makes sense, but would not want it to be much longer than that. If it was 2min then pretty sure that person already closed the window and perhaps we could look at introducing some other indicator like progress or messaging to let the person know that something is still being fetched until it fails.

In T295670#7931414, @RHo wrote:

In T295670#7926700, @kostajh wrote:

I'm not sure that there is anything to do here? Sometimes requests time out. I suppose we could present a message to the user that this is happening with a prompt to retry the request (the request is to fetch suggested edits tasks, usually) and not log the error? @RHo what do you think?

I might need a little more context but I'm firstly curious if we know on average how long before it times out? If it was 20-30sec then an error message and retry action definitely makes sense, but would not want it to be much longer than that. If it was 2min then pretty sure that person already closed the window and perhaps we could look at introducing some other indicator like progress or messaging to let the person know that something is still being fetched until it fails.

@RHo we're using MediaWiki's API helper class, which sets a default value of 30 seconds for the XMLHttpRequest timeout value. We could lower or raise that number. Maybe something like 10 seconds is closer to the upper limit of what users would tolerate, so if the request hasn't finished by then, we should offer that they can manually retry it.

In terms of how the user might be impacted by timeouts, a few scenarios are:

• when interacting with topic/task filter dialogs, and waiting a long time to see the result counter change. We have a spinner showing that something is happening. Closing the dialog and reopening is a way to restart the query now, as is adjusting the topic/task selections.
• when waiting for a task to appear in the post-edit dialog.
• after clicking "next" on the first task in the suggested edits feed. The first one is rendered on the server-side, but after that we begin to fetch tasks from a client side API call. We could probably rework the code to not require an API request for initial browsing of the queue, since we have 20 tasks already.

In T295670#7932591, @kostajh wrote:

In T295670#7931414, @RHo wrote:

In T295670#7926700, @kostajh wrote:

I'm not sure that there is anything to do here? Sometimes requests time out. I suppose we could present a message to the user that this is happening with a prompt to retry the request (the request is to fetch suggested edits tasks, usually) and not log the error? @RHo what do you think?

I might need a little more context but I'm firstly curious if we know on average how long before it times out? If it was 20-30sec then an error message and retry action definitely makes sense, but would not want it to be much longer than that. If it was 2min then pretty sure that person already closed the window and perhaps we could look at introducing some other indicator like progress or messaging to let the person know that something is still being fetched until it fails.

@RHo we're using MediaWiki's API helper class, which sets a default value of 30 seconds for the XMLHttpRequest timeout value. We could lower or raise that number. Maybe something like 10 seconds is closer to the upper limit of what users would tolerate, so if the request hasn't finished by then, we should offer that they can manually retry it.

Yes, maybe 15seconds (to split the difference) before there is a dialog or message with an action to retry?

In terms of how the user might be impacted by timeouts, a few scenarios are:

• when interacting with topic/task filter dialogs, and waiting a long time to see the result counter change. We have a spinner showing that something is happening. Closing the dialog and reopening is a way to restart the query now, as is adjusting the topic/task selections.

• This seems sufficient to me.

• when waiting for a task to appear in the post-edit dialog.

• We have a task for this already that I've updated today T294835: Positive reinforcement: Revise skeleton state and behaviour of the Post-edit dialog

• after clicking "next" on the first task in the suggested edits feed. The first one is rendered on the server-side, but after that we begin to fetch tasks from a client side API call. We could probably rework the code to not require an API request for initial browsing of the queue, since we have 20 tasks already.

• Yes, that would be great.

In T295670#7939214, @RHo wrote:

In T295670#7932591, @kostajh wrote:

In T295670#7931414, @RHo wrote:

In T295670#7926700, @kostajh wrote:

I'm not sure that there is anything to do here? Sometimes requests time out. I suppose we could present a message to the user that this is happening with a prompt to retry the request (the request is to fetch suggested edits tasks, usually) and not log the error? @RHo what do you think?

I might need a little more context but I'm firstly curious if we know on average how long before it times out? If it was 20-30sec then an error message and retry action definitely makes sense, but would not want it to be much longer than that. If it was 2min then pretty sure that person already closed the window and perhaps we could look at introducing some other indicator like progress or messaging to let the person know that something is still being fetched until it fails.

@RHo we're using MediaWiki's API helper class, which sets a default value of 30 seconds for the XMLHttpRequest timeout value. We could lower or raise that number. Maybe something like 10 seconds is closer to the upper limit of what users would tolerate, so if the request hasn't finished by then, we should offer that they can manually retry it.

Yes, maybe 15seconds (to split the difference) before there is a dialog or message with an action to retry?

That sounds good to me; I think the next step would be to think about what the UX would look like (a popup dialog with a button to retry, like VisualEditor has?), and what the wording should be. And it should probably be instrumented as well.

In terms of how the user might be impacted by timeouts, a few scenarios are:

• when interacting with topic/task filter dialogs, and waiting a long time to see the result counter change. We have a spinner showing that something is happening. Closing the dialog and reopening is a way to restart the query now, as is adjusting the topic/task selections.

• This seems sufficient to me.

+1

• when waiting for a task to appear in the post-edit dialog.

• We have a task for this already that I've updated today T294835: Positive reinforcement: Revise skeleton state and behaviour of the Post-edit dialog

Ah, great. Thanks!

• after clicking "next" on the first task in the suggested edits feed. The first one is rendered on the server-side, but after that we begin to fetch tasks from a client side API call. We could probably rework the code to not require an API request for initial browsing of the queue, since we have 20 tasks already.

• Yes, that would be great.

I started experimenting with this in T308542: Suggested edits: Populate task queue from server-side.

In T295670#7940975, @kostajh wrote:

In T295670#7939214, @RHo wrote:

In T295670#7932591, @kostajh wrote:

@RHo we're using MediaWiki's API helper class, which sets a default value of 30 seconds for the XMLHttpRequest timeout value. We could lower or raise that number. Maybe something like 10 seconds is closer to the upper limit of what users would tolerate, so if the request hasn't finished by then, we should offer that they can manually retry it.

Yes, maybe 15seconds (to split the difference) before there is a dialog or message with an action to retry?

That sounds good to me; I think the next step would be to think about what the UX would look like (a popup dialog with a button to retry, like VisualEditor has?), and what the wording should be. And it should probably be instrumented as well.

How about something like this:

In T295670#7944401, @RHo wrote:

In T295670#7940975, @kostajh wrote:

In T295670#7939214, @RHo wrote:

In T295670#7932591, @kostajh wrote:

@RHo we're using MediaWiki's API helper class, which sets a default value of 30 seconds for the XMLHttpRequest timeout value. We could lower or raise that number. Maybe something like 10 seconds is closer to the upper limit of what users would tolerate, so if the request hasn't finished by then, we should offer that they can manually retry it.

Yes, maybe 15seconds (to split the difference) before there is a dialog or message with an action to retry?

That sounds good to me; I think the next step would be to think about what the UX would look like (a popup dialog with a button to retry, like VisualEditor has?), and what the wording should be. And it should probably be instrumented as well.

How about something like this:

It uses the OOUI name | Message dialog (2 actions)]] and I was thinking the following message copy:
Heading: Request timed out
Text: The request took too long to respond. Would you like to retry?
Primary (progressive) CTA button label: Try again

That looks good to me, though I'd suggest a minor change on the wording to: The request took too long to complete. Would you like to retry?

In T295670#7949468, @kostajh wrote:

In T295670#7944401, @RHo wrote:

In T295670#7940975, @kostajh wrote:

In T295670#7939214, @RHo wrote:

In T295670#7932591, @kostajh wrote:

@RHo we're using MediaWiki's API helper class, which sets a default value of 30 seconds for the XMLHttpRequest timeout value. We could lower or raise that number. Maybe something like 10 seconds is closer to the upper limit of what users would tolerate, so if the request hasn't finished by then, we should offer that they can manually retry it.

Yes, maybe 15seconds (to split the difference) before there is a dialog or message with an action to retry?

That sounds good to me; I think the next step would be to think about what the UX would look like (a popup dialog with a button to retry, like VisualEditor has?), and what the wording should be. And it should probably be instrumented as well.

How about something like this:

It uses the OOUI name | Message dialog (2 actions)]] and I was thinking the following message copy:
Heading: Request timed out
Text: The request took too long to respond. Would you like to retry?
Primary (progressive) CTA button label: Try again

That looks good to me, though I'd suggest a minor change on the wording to: The request took too long to complete. Would you like to retry?

Sure, SGTM!

@RHo based on https://www.nngroup.com/articles/response-times-3-important-limits/, I wonder if we should consider a lower timeout limit, like 5 or 10 seconds.