Skip to content
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

improvement: add timeout to requests #5452

Merged
merged 6 commits into from
Jan 2, 2024

Conversation

kasiaMarek
Copy link
Contributor

@kasiaMarek kasiaMarek commented Jul 14, 2023

In some erroneous situations build server fails to respond, which in metals for e.g. compilation blocks the queue. This PR adds timeout to the requests, so in such situations we can recover.

@kasiaMarek
Copy link
Contributor Author

We want to add minTimeout and minCompileTimeout to sever config, right?

@kasiaMarek kasiaMarek requested a review from tgodzik July 14, 2023 13:53
@kasiaMarek kasiaMarek force-pushed the request-timeout branch 2 times, most recently from 27537cf to 5d86988 Compare July 21, 2023 13:35
@kasiaMarek kasiaMarek marked this pull request as ready for review October 13, 2023 12:18
@kasiaMarek kasiaMarek requested a review from jkciesluk October 13, 2023 12:19
Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for getting back so late to this. I think we can change this up a bit to avoid any risk that people would get things cancelled without them even knowing about it.

import scala.meta.internal.metals.CancelableFuture
import scala.meta.internal.metals.MetalsEnrichments._

object FutureWithTimeout {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could go another direction. Instead of relying on Await, we could save the request time and if another request comes in the queue and the timeout is calculated to be too much (using FlexTimeout) we could ask the user if they want to cancel it:

$name request is taking longer than expected, do you want to cancel and rerun it?
Cancel | Wait | Wait always

If they wait we could triple the flex time and ask again at some point. Wait always would imply that they don't want to show those pop ups, which could be safe if the feature is not 100 % at the start.

@kasiaMarek kasiaMarek marked this pull request as draft November 22, 2023 16:45
Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two more thoughts, but otherwise looks almost ready to merge.

@@ -211,6 +226,7 @@ class BuildServerConnection private (
register(
server => server.buildTargetScalaMainClasses(params),
onFail,
defaultTimeout("main classes"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing I realised is that, if a user is hit with that message, they wouldn't know what is going on. Most likely it's enough to show notification on compilation and otherwise cancel main/test automatically with a warning. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Let's not ask in such case.

](compile, "cascadeBatch", shouldLogQueue = true, Some(Map.empty))
](
compile(timeout = None),
"cascadeBatch",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we cancel this if we cancel normal compilation also? Since most likely this will also not finish. Cascade compile is normal compile, but on more targets.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I set the minimum timeout to 15 min for that.

@kasiaMarek kasiaMarek marked this pull request as ready for review December 28, 2023 10:08
@kasiaMarek kasiaMarek requested a review from tgodzik December 28, 2023 10:08
Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@kasiaMarek kasiaMarek merged commit fe020f8 into scalameta:main Jan 2, 2024
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants