I'm also curious as to what the issue was, as we've been doing Python-client-Java-server auth with development builds without trouble.
Regardless - this does point out a need for more cross-language Flight testing (perhaps a Flight-specific integration suite?), and to get existing tests running more consistently in CI (Flight/Java in particular has a lot of flaky tests, though the auth tests are enabled in Travis). Best, David On 7/4/19, Jacques Nadeau <jacq...@apache.org> wrote: > Which is exactly why I was withholding a vote until there was more > information. > > On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou <solip...@pitrou.net> wrote: > >> On Thu, 4 Jul 2019 09:04:34 -0500 >> Wes McKinney <wesmck...@gmail.com> wrote: >> > >> > That being said, with Ryan's issue, he is using a feature >> > (cross-language auth in Flight) that isn't being tested. The Flight >> > integration tests do not use authentication AFAIK so I'm not surprised >> > to hear that there may be an issue with it. >> >> OTOH, it's a bit unlikely. Flight authentication is implemented is: >> - the Arrow codebase simply passes opaque tokens around >> - interpretation of tokens is handled by application code >> - marshalling of tokens is handled by Protocol Buffers >> >> So unless something silly is going on (such as "passing an empty string >> instead of the actual token") there's not much potential for >> auth interoperability issues in the core Flight codebase. >> >> Regards >> >> Antoine. >> >> >> >