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

Testing locally: Expected environment variable GAE_SERVICE to be set! #87

Closed
mwalkerwells opened this issue Nov 5, 2018 · 2 comments · Fixed by #113
Closed

Testing locally: Expected environment variable GAE_SERVICE to be set! #87

mwalkerwells opened this issue Nov 5, 2018 · 2 comments · Fixed by #113

Comments

@mwalkerwells
Copy link

After following the instructions found in the README.md (https://github.com/dart-lang/appengine#running-the-app-locally), I get the following error using docker and dart ./bin/server.dart.

Error

Bad state: Expected environment variable GAE_SERVICE to be set!

Dart

Dart VM version: 2.0.0 (Fri Aug 3 10:53:23 2018 +0200) on "macos_x64"

Docker

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:31 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     true

Error

docker build .
docker run -it <hash>

Observatory listening on http://0.0.0.0:8181/
Unhandled exception:
Bad state: Expected environment variable GAE_SERVICE to be set!
#0      _initializeAppEngine._findEnvironmentVariable (package:appengine/src/appengine_internal.dart:145:7)
#1      _initializeAppEngine (package:appengine/src/appengine_internal.dart:164:31)
<asynchronous suspension>
#2      _withAppEngineServicesInternal.<anonymous closure> (package:appengine/src/appengine_internal.dart:106:45)
<asynchronous suspension>
#3      _ServiceScope._fork.<anonymous closure> (package:gcloud/service_scope.dart:210:19)
#4      _rootRun (dart:async/zone.dart:1124:13)
#5      _CustomZone.run (dart:async/zone.dart:1021:19)
#6      _runZoned (dart:async/zone.dart:1516:10)
#7      runZoned (dart:async/zone.dart:1463:12)
#8      _ServiceScope._fork (package:gcloud/service_scope.dart:209:12)
#9      fork (package:gcloud/service_scope.dart:104:30)
#10     _withAppEngineServicesInternal (package:appengine/src/appengine_internal.dart:105:10)
#11     runAppEngine (package:appengine/src/appengine_internal.dart:56:10)
#12     runAppEngine (package:appengine/appengine.dart:62:10)
#13     main (file:///app/bin/server.dart:11:3)
<asynchronous suspension>
#14     _startIsolate.<anonymous closure> (dart:isolate/runtime/libisolate_patch.dart:279:19)
#15     _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:165:12)
@tvolkert
Copy link
Collaborator

tvolkert commented Aug 1, 2019

I was getting this error reliably when my workstation was connected to the Internet via my cell phone hotspot Wifi, and I traced it to:

final response = await client.get(

That HTTP GET was resulting in the following content (line breaks and spaces added by me):

<html>
  <head>
    <meta http-equiv="refresh" content="0;url=http://lookup.t-mobile.com/search/?q=http://metadata.google.internal/computeMetadata/v1/instance/zone&t=0"/>
  </head>
  <body>
    <script>window.location="http://lookup.t-mobile.com/search/?q="+escape(window.location)+"&r="+escape(document.referrer)+"&t=0";</script>
  </body>
</html>

So it seems that an HTTP proxy can mess with the logic that is used to determine if we're running in a development environment or production environment...

@tvolkert
Copy link
Collaborator

tvolkert commented Aug 1, 2019

Under normal circumstances in a dev environment, a SocketException is thrown:

} on SocketException {
// likely not on cloud
return null;

So the issue (at least in my case) was that a proxy caused a connection that otherwise would not have been able to be established to succeed, and to return an html page rendered by the proxy.

Maybe the HTTP 200 case should check for <html> as a sentinel for the request having been intercepted?

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 a pull request may close this issue.

2 participants