nit: Try not to let your editor take out single blank lines. This one give some visual separation of the return statement from the logic of the function, which aid in "scanning" the code late.

Does the API require us to spend a key and value with blank values specifically?
Seems unnecessary--is it a limitation of the proto system?

It's not a limitation of the API, rather the following:
We are fetching the default group here, which has the following characteristics:
Only the auth provider ID is set within the properties, both key and value are empty, and the role name has to match.
Hence, the explicitly empty key and value within the query, otherwise this would not be needed.

Since we are talking about it, it seems to need additional clarification, I've added a comment explaining more the reason as to why both key and value are specified as empty explicitly.

I thought that 'empty' and 'absence' will map to the same logical situation: don't filter by this field.

No, surprisingly not.

Say you have two groups:

{"props":{"authProviderId":"0ceed22f-026f-41a2-9d91-96410e4c4846","key":"","value":""},"roleName":"Scope Manager"}
{"props":{"authProviderId":"0ceed22f-026f-41a2-9d91-96410e4c4846","key":"email","value":"something"},"roleName":"Scope Manager"}

both groups are mapping to the role name Scope Manager.

Executing a request, i.e. via curl, you will retrieve the following without explicit empty fields:

curl <endpoint>/v1/groups?authProviderId=0ceed22f-026f-41a2-9d91-96410e4c4846&roleName="Scope Manager"

response:
{"groups":[{"props":{"authProviderId":"0ceed22f-026f-41a2-9d91-96410e4c4846","key":"","value":""},"roleName":"Scope Manager"},{"props":{"authProviderId":"0ceed22f-026f-41a2-9d91-96410e4c4846","key":"email","value":"something"},"roleName":"Scope Manager"}]}

Instead, if you execute the request with explicitly setting key and value to empty strings, you will receive the following:

curl <endpoint>/v1/groups?authProviderId=0ceed22f-026f-41a2-9d91-96410e4c4846&roleName="Scope Manager"&key=&value=

response:
{"groups":[{"props":{"authProviderId":"0ceed22f-026f-41a2-9d91-96410e4c4846","key":"","value":""},"roleName":"Scope Manager"}]}

TL;DR: we do need to explicitly set those, otherwise we return other groups that are not the default created one.

I thought that 'empty' and 'absence' will map to the same logical situation: don't filter by this field.

Does this mean that if multiple default groups have been created (should be possible now from the backend perspective, e.g., via curl), a batch group request will delete all except the one that we stored here? Looks like a bug.

@rukletsov Can you elaborate on what you now expect for multiple default groups?

Just because it is technically possible through the API, is it a requirement, or even an option, that we need to expose to customers?

The current UI has one form input, labelled "Minimum access role" that only allows you select one role from a list. Has this requirement changed?

@rukletsov
While I agree it's technically possible to do so, I feel like we should be more strict on the datastore regarding this ambiguity.

I don't think we are ready to change requirements in the UI for this, i.e. allowing multiple "Minimum access roles" to be set (which would turn out to be multiple default groups) nor do I personally want this, from a user point of view it would be confusing.

Instead, if we decide to do anything, I feel we should restrict the API. Iff the client creates a group with only the auth provider ID set, it's not possible to do so when another group with only the same auth provider ID set exists. This way, we wouldn't have to deal with the ambiguity in the UI, can keep it as-is, and don't have to worry about potentially removing default groups here. However, this would mean we restrict the behavior from the API.

Otherwise, if we decide to change anything in the UI, how would you even know which default group to change? Let's say you have multiple groups with the same role name (which is what you would yield here): which group is the one originally created, and which is the one not and shouldn't be changed?

If you will forgive a question out of an abundance of ignorance, is there any situation in which groups might be an empty array? Or more relevant, any situation which a user can cause to happen?

Apparently yes, because getGroupsWithDefault function has conditional logic for the situation:

// The default group is not yet created, meaning we have to make sure we create it here.
// Set the auth provider ID and role name.
// Use the default group if we receive a value here.

This is one of the most important files in services folder that is still JavaScript. Adding types/group.proto.ts and rewriting this file in TypeScript might be a good collaborative follow up for UI and Merlin in 72.

@pedrottimark Yes, this may happen.
It could be, as you rightly mentioned, that the auth provider is currently eing created and the default group has not been created yet or the default group has been deleted via API (which is unlikely, but still possible).

I agree on the collaborative effort to migrate this to typescript, it would certainly make life better. I've created ROX-11600 for that with the aim to complete it within 3.72.

@vjwilson @dhaus67 Let's restrict the API to at most one default rule / group per auth provider. @dhaus67 could you please send a new PR in this chain for this?