Firebase Performance doesn't accept spaces inside attribute names

[sp-jordi-vilalta]

Description

According to the Firebase Performance documentation, these are the requirements for the name of the custom attributes:

Names for custom attributes must meet the following requirements: no leading or trailing whitespace, no leading underscore (_) character, and max length is 32 characters.

Trying to set an attribute with a space in its name (like my attribute) fails with these log messages:

[FirebasePerformance][I-PRF500004] Illegal characters used for attribute name, characters allowed are alphanumeric or underscore.
[FirebasePerformance][I-PRF500001] Failed to initialize because of a nil or zero length attribute name.

The code doesn't match the documentation:

• it only allows alphanumeric characters and underscores
• it allows underscores at the beginning of the name

Ideally I would like to be able to use spaces inside attribute names (as the documentation implies), since those names are user-visible in the dashboard and it would make them much more readable by non-technical people

Reproducing the issue

No response

Firebase SDK Version

9.4.0

Xcode Version

13.4.1

Installation Method

CocoaPods

Firebase Product(s)

Performance

Targeted Platforms

iOS

Relevant Log Output

No response

If using Swift Package Manager, the project's Package.resolved

No response

If using CocoaPods, the project's Podfile.lock

No response

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[visumickey]

Thanks for reporting the discrepancy here. Really appreciate the references to showcase the gaps. Unfortunately, we have some limitations in allowing space in the custom attribute names. So, at this time we don't support it. As we see this as a bottleneck to more developers, we will definitely be able to make this a possibility.

As an alternate, would replacing space with a _ work for easy reading clarity? Definitely not a great replacement, but still checking on it as a possibility.

[sp-jordi-vilalta]

It makes sense. The main issue here is the discrepancy with the documentation: adding a new attribute with a seemingly innocent name and not receiving it in the dashboard can lead to extra investigation and waste of time for the developers. If the documentation gets updated to make these limitations clear, it would be fine.

On the other hand there's the user experience on the dashboard. As you suggested, replacing spaces with underscores makes it more readable. As an extra step (quality of life improvement) maybe underscores could be automatically replaced with spaces when showing attribute names to end users? I understand the current behavior may be the expected one in some cases, so no big deal.

Proposal: Add a way to tell when attribute names are intended to be "human readable", for example with a trailing underscore. With that, my_attribute_name would be shown as is in the dashboard, but My_attribute_name_ could be shown as "My attribute name".

[morganchen12]

Googlers see cl/482629530 for documentation updates.

[visumickey]

@sp-jordi-vilalta Thanks for the suggestion and the feature request. I like the idea of turning it into a human readable form. I will followup internally to see if there are any concerns in using this idea (For eg: there any many other developers our there who use their AB testing experiment IDs with underscores and it might confuse them to turn off the underscores).

For now, we are working on updating our external documentation to fix this discrepancy. Thanks again for highlighting the issue. Appreciate you reporting the discrepancy!