-
Notifications
You must be signed in to change notification settings - Fork 340
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
Conversation
We want to add |
27537cf
to
5d86988
Compare
5d86988
to
4314047
Compare
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.
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 { |
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 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.
4314047
to
8d006d4
Compare
8d006d4
to
7c0251d
Compare
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.
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"), |
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.
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?
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's not ask in such case.
](compile, "cascadeBatch", shouldLogQueue = true, Some(Map.empty)) | ||
]( | ||
compile(timeout = None), | ||
"cascadeBatch", |
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.
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.
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 set the minimum timeout to 15 min for that.
…to cascade compile
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!
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.