appengine

appengine copied to clipboard

google.golang.org/appengine/v2 is offered as a transition strategy for GAE apps to use some of the longer-term supported GAE services while escaping the go111 runtime. However, the two packages both internally use a remote_api subpackage generated from a protobuf, and the two versions share the same package name, which generates a conflict in the proto registry when the two packages are present anywhere in the same binary. The migration notes don't mention that the two can't be in the same import closure simultaneously, and the only way to figure out the problem is to match the offending proto package against the entire dependency closure, where one eventually finds it in the appengine/internal subpackage.

I get that the two versions aren't meant to be used simultaneously, since v2 is acting as an API bridge, but not even having it be possible to be present in the same binary makes an even bigger refactoring burden to the one already involved in getting off the legacy runtime. Since the appengine package contains common datatypes like GeoPoint, utility functions like IsDevAppServer(), and all the serving-setup calls, it tends to get used in a lot of different parts of a codebase, which may have dependencies on one another. To do an incremental migration in an established codebase requires a strategy like moving all the appengine dependencies to a swappable top-level package first, which is the sort of migration trouble it seemed the v2 package was meant to avoid.

There's a basic repro case at https://github.com/aqua/gae-version-conflict-bug (the thing1 tests pass, the thing2 tests panic; more recent protobuf versions panic, older ones log about undefined behavior) if you want one.