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.

Sign up for GitHub

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

Jump to bottom

x/playground: change vet support to happen in 1 HTTP request/response instead of 2 #31970

Open
bradfitz opened this issue May 10, 2019 · 3 comments
Open

x/playground: change vet support to happen in 1 HTTP request/response instead of 2 #31970

bradfitz opened this issue May 10, 2019 · 3 comments
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unreleased

Comments

@bradfitz
Copy link
Contributor

Currently the playground makes 2 HTTP requests (/compile + /vet) instead of just 1.

(Noticed while working on #31944)

We need to do this first, otherwise the implementation of #31944 either gets nasty, or slow.

So let's just clean this up first.

Plan:

  • keep old handler, to support older javascript clients
  • add new "withvet=1" URL parameter to advertise to server that the client supports vet in one round trip
  • return "vet" object in returned JSON
  • have client skip /vet XHR if vet object key is returned

/cc @ysmolsky
@bradfitz bradfitz added the NeedsFix The path to resolution is known, but the work has not been done. label May 10, 2019
@bradfitz bradfitz added this to the Unreleased milestone May 10, 2019
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/176598 mentions this issue: playground: let clients request vet check in same HTTP request as compile+run

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/176618 mentions this issue: playground.js: let client use vet check returned by /compile endpoint

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/176939 mentions this issue: godoc/static: let client use vet check returned by /compile endpoint

gopherbot pushed a commit to golang/tools that referenced this issue May 13, 2019
@bradfitz
godoc/static: let client use vet check returned by /compile endpoint
2a413a0 
(Forked off Yury Smolsky's CL 176618)

With this change, the playground.js client now asks the server to do a
vet check in the same HTTP request as the /compile (and run) step. If
the server replies that it understands the request (VetErrors or VetOK
in the repsonse), then the client can avoid the latency of a second
HTTP roundtrip. We'll remove the /vet handler after we see it fall out
of use from older clients.

Updates golang/go#31970

Change-Id: I5b123883e19cbc6a8ec30c50705e6b945a4d322d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/176939
Reviewed-by: Andrew Bonventre <andybons@golang.org>
gopherbot pushed a commit to golang/playground that referenced this issue May 13, 2019
@bradfitz
playground: let clients request vet check in same HTTP request as com…
1cc919a 
…pile+run

Also, move the tests to their own file and extend them a bit, give
them names, and make the test step more verbose (only visible in
docker build anyway). They were hogging up the sandbox file.

Updates golang/go#31970

Change-Id: Id710ea613c77a5b16cc5e79545c0812d0f4650e3
Reviewed-on: https://go-review.googlesource.com/c/playground/+/176598
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Yury Smolsky <yury@smolsky.by>
henderjon pushed a commit to oggodoc/godoc that referenced this issue Jun 13, 2024
@bradfitz
godoc/static: let client use vet check returned by /compile endpoint
58a502c 
(Forked off Yury Smolsky's CL 176618)

With this change, the playground.js client now asks the server to do a
vet check in the same HTTP request as the /compile (and run) step. If
the server replies that it understands the request (VetErrors or VetOK
in the repsonse), then the client can avoid the latency of a second
HTTP roundtrip. We'll remove the /vet handler after we see it fall out
of use from older clients.

Updates golang/go#31970

Change-Id: I5b123883e19cbc6a8ec30c50705e6b945a4d322d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/176939
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
2 participants
@bradfitz @gopherbot