-
Notifications
You must be signed in to change notification settings - Fork 48
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
Compile asynchronously #890
Compile asynchronously #890
Conversation
@daimor @gjsjohnmurray The internal devs verified that this fixed the 504 error. I think you should both try this out before it gets merged though. |
Maybe cancellation should add a message to the output channel, in case the partially-compiled classes on the server result in unexpected behaviour. |
@isc-bsaviano as mentioned on today's call, you'll look to address my feedback re a cancel message. I don't see this as a showstopper though, so if @daimor is happy with what's already in this PR but you don't get to the cancel message thing imminently I suggest merging as-is so it can get into the upcoming release. |
@gjsjohnmurray I will add a cancellation message, I think that's good to have |
@gjsjohnmurray If the message looks ok to you I will merge this. |
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.
👍
This PR removes the use of the synchronous
/action/compile
API and instead uses the/work
endpoints to compile documents. We've had reports internally of users running into504 Gateway Timeout
errors when compiling a class took more than 60 seconds. While the users could increase the timeout, they could always run up against it again in the future. Using this approach ensures that the extension will not break, regardless of how long compilation on the server may take.I'm leaving this as a draft until the people who ran into the gateway timeout issue internally verify that this works for them.