Re: Yksityinen viesti liittyen aiheeseen New Variant: "1800: Empires And Coalitions"

4 views
Skip to first unread message

Martin Bruse

unread,
Feb 26, 2020, 11:12:04 AM2/26/20
to IAMTERMINATOR, diplic...@googlegroups.com

OOoh.

It seems the recent-ish update to more modern App Engine environment has broken more than I thought. It used to be that the server could know if the client used HTTP or HTTPS by looking at the Request.TLS object. Now, it can't - this object is always nil since App Engine forwards TLS requests to the app as regular HTTP requests...

I have been trying to change the rest of the URL calculation like I did to work around this before: All local development servers will use HTTP, and all non-local development servers will use HTTPS.

I still haven't made it work though.

(This might explain why the server has gone up and down a lot the last hour or so)

Tom: Don't release the server now! It's running on an old version, and the newest code breaks login :/

On Wed, Feb 26, 2020, 13:37 IAMTERMINATOR <ruben...@gmail.com> wrote:
Version 439 on Android 9, right after I try to inspect game.

tiistai 25. helmikuuta 2020 22.44.49 UTC+2 Martin Bruse kirjoitti:
> Can you show me a screenshot of when the error happens?
> Also, what version of the app are you using?
>
>
> On Tue, Feb 25, 2020, 21:42 IAMTERMINATOR <ruben...@gmail.com> wrote:
> Every game seems to return that error message instead of showing map. I have no started games yet but I would like to start a few after short break from the game, but only thing I'm getting is that message.
>
> Sorry for posting this problem here since it seems to affect all games/variants
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "diplicity-talk" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to diplici...@googlegroups.com.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/diplicity-talk/a944c9e0-d509-4097-937e-3057e6a516c9%40googlegroups.com.

Martin Bruse

unread,
Feb 26, 2020, 11:28:53 AM2/26/20
to IAMTERMINATOR, diplic...@googlegroups.com, diplicity-talk
+diplici...@googlegroups.com

Please note that we have a messy bug right now that makes it impossible to see starting maps of not yet started games.

Martin Bruse

unread,
Feb 26, 2020, 5:42:35 PM2/26/20
to Ttt Ppp, diplic...@googlegroups.com, diplicity-talk
Alright, I now know what went wrong, and I was able to change all the generated URLs without breaking the matching of incoming URLs.

It was trickier than expected, mainly because I was stupid enough to clean up some other things at the same time...

What I haven't been able to do is to remove the 'Scheme' property of the 'Phase' class, even if it's no longer used. Since Datastore complains if loaded objects contain fields missing from the class definition that was simply too much of a hassle.

I might clean that up later on. We'll see.

The biggest problem is that I was unable to run the tests on my laptop, since something kills the server after a random number of test requests. I suspect something nasty has changed with the App Engine dev server that breaks some assumptions my tests made.

If anything doesn't work as expected, please report it ASAP to mitigate this hopefully temporary lack of testing.

Best,
Martin

On Wed, Feb 26, 2020 at 5:48 PM Martin Bruse <zond...@gmail.com> wrote:
I think it has to do with the server generating http links, but doesn't properly handle anything but https.

I'm not sure why most things still worked, but now that I explicitly make all links https (except for local dev server), I somehow messed up the way OAuth redirects back to the server, and it doesn't accept the redirect anymore.

I hope to fix it tonight or tomorrow.


On Wed, Feb 26, 2020, 17:45 Ttt Ppp <tttp...@gmail.com> wrote:
Ok - I won't touch anything.

I'm not sure what the issue is though, because I was able to see the starting maps fine (using the latest 439 app release and live server).

When I googled that issue about net::ERR_CLEARTEXT_NOT_PERMITTED then there was a suggestion to include android:usesCleartextTraffic="true" in the map WebView.
To unsubscribe from this group and stop receiving emails from it, send an email to diplicity-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diplicity-talk/c359fee7-85f6-4d13-afba-71f021a94063%40googlegroups.com.

Martin Bruse

unread,
Feb 27, 2020, 4:21:38 AM2/27/20
to Ttt Ppp, diplic...@googlegroups.com
For posterity, here is a more detailed explanation:

App Engine used to let the Go runtime terminate the TLS connection, so that I could check whether we were using TLS in the code, and select 'http' or 'https' to all generated absolute URLs.

Nowadays it doesn't, which means that some parts of the app thought we were running without TLS.

Thus, some links got created with 'http' instead of 'https'.

This often worked, for some reason, even if the app required TLS everywhere - since the app, for some magical reason, redirected 'http' requests to the same URL but with 'https' for most things.

For the naked SVG map however, it didn't - I don't know why.

So what I did was I made the main binary (app.go) select DefaultScheme in github.com/zond/goaeoas (which generates most links) based on appengine.IsDevAppServer(). Then, for all the places where links were generated outside goaeoas, I used DefaultScheme instead of checking the TLS value in the incoming request.

My breakage while doing this was because I didn't read the documentation for https://github.com/gorilla/mux properly, and thought that I could use the router-generated URLs, but just set Scheme and Host for them to make working absolute URLs.

What I didn't know was that the side effect was that the instance that created this URL also added a new matcher to the router - which didn't work since a lot of incoming requests don't seem to have Host or Scheme set (don't know why?).

Then when all this was fixed, I noticed that some games didn't resolve. Now I found that error as well! It's because the google.golang.org/appengine/delay package has changed behaviour between Go 1.9 and 1.11 - the generated keys for the delayed functions are now different, so all delayed functions created before my update will fail when they try to run.

The weird thing is that we switched from Go 1.9 to Go 1.11 well before yesterday, so this error shouldn't be new. I have no idea why it happened now... Maybe I hadn't updated my SDK or something?

I noticed that the code for google.golang.org/appengine/delay isn't provided by the server, but by me when I deploy (that's why I suspect an older local SDK might have caused the changed behaviour). So I changed some bits in delay.go:

--- a/delay/delay.go
+++ b/delay/delay.go
@@ -323,9 +323,20 @@ func runFunc(c context.Context, w http.ResponseWriter, req *http.Request) {
 
        f := funcs[inv.Key]
        if f == nil {
-               log.Errorf(c, "delay: no func with key %q found", inv.Key)
-               log.Warningf(c, "delay: dropping task")
-               return
+               invSplit := strings.Split(inv.Key, ":")
+               keys := []string{}
+               for k, fnc := range funcs {
+                       foundSplit := strings.Split(k, ":")
+                       if len(invSplit) == 2 && len(foundSplit) == 2 && invSplit[1] == foundSplit[1] {
+                               f = fnc
+                       }
+                       keys = append(keys, k)
+               }
+               if f == nil {
+                       log.Errorf(c, "delay: no func with key %q found among %+v", inv.Key, keys)
+                       log.Warningf(c, "delay: dropping task")
+                       return
+               }
        }

that I hope will mitigate this for a while. The next release from a different machine than mine will remove this patch, but hopefully all old tasks will be finished by then.

NB: I'm pretty annoyed with the engineers that made the decision to fail all previously generated tasks when you upgrade from Go 1.9 to Go 1.11. Especially since the tasks are just dropped, without any retries or efforts to resolve the problem.

Reply all
Reply to author
Forward
0 new messages