fetchProvidersForEmail returns null on iOS, empty array on Android

[timtraversy]

[REQUIRED] Step 2: Describe your environment

• Xcode version: 11.0 beta (11M336w)
• Firebase SDK version: 6.0
• Firebase Component: Auth
• Component version: 6.0

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

In this library, a call to fetchProvidersForEmail() with an email that is not registered returns null. That's because the HTTP response to createAuthURI() is

"kind" : "identitytoolkit#CreateAuthUriResponse"	
"sessionId" : "xxxxxxxxxxx"	
"registered" : NO

And when this is parsed into a FIRCreateAuthURIResponse this function sets _allProviders to null:

firebase-ios-sdk/Firebase/Auth/Source/Backend/RPC/FIRCreateAuthURIResponse.m

Lines 23 to 32 in 331f651

	- (BOOL)setWithDictionary:(NSDictionary *)dictionary
	error:(NSError *_Nullable *_Nullable)error {
	_providerID = [dictionary[@"providerId"] copy];
	_authURI = [dictionary[@"authUri"] copy];
	_registered = [dictionary[@"registered"] boolValue];
	_forExistingProvider = [dictionary[@"forExistingProvider"] boolValue];
	_allProviders = [dictionary[@"allProviders"] copy];
	_signinMethods = [dictionary[@"signinMethods"] copy];
	return YES;
	}

However, the android version of this library returns an empty list. I'm not sure how its implemented there because it's not been published in https://github.com/firebase/firebase-android-sdk.

This causes a problem in the FlutterFire auth package because the response seems expected to be an array, not null, as you can see in this test: https://github.com/flutter/plugins/blob/f401ca1ce107f3ac7a589715cf69e101ac9f40d3/packages/firebase_auth/test/firebase_auth_test.dart#L277-L281
This isn't an integration test which is why it didn't throw an error.

I think fetchProvidersForEmail() should return an empty array if there are no providers, so that it matches the Android behavior and the expectations of the FlutterFire package. If that sounds right I can create a PR, but that might be better done by someone who can see the internal Android code.

[malcolmdeck]

Hey! So I've synced with the team about this and we've come to the following recommendation set:

1. If this is causing technological problems for the Flutter SDK (such as if there is no way to coalesce these two distinct values in your software), please file a bug internally to the Firebase Auth SDK team so that we can try to include it in the next appropriate set of changes (this will take a while).

2. If you do have a way of coalescing these values but are trying to decide which response is appropriate, please map an iOS NULL to an empty array for your public API.

Unfortunately, it may be a while before we can make these align in our SDK-set - to change the response value of a public API is a "breaking change," in that making that change could break developers that rely on its current implementation should they upgrade. Given that that is the case, I would not anticipate a particularly expedient resolution to this issue - we don't ship breaking changes very often.

Fortunately, the problem is only cosmetic - there is no semantic distinction between those two responses (though in theory there could be if we consider anonymous accounts with emails as a distinct case from when our DB has no record of an email at all - there are legacy reasons that we don't make this distinction).

[timtraversy]

Got it, thanks! I'll close this since no immediate action needs to be taken. I've opened a Flutter PR with a coalescing solution, since that's where this issue is currently producing unexpected results.