Handle GeoJSON int to str conversion when the name is an int

[codyc1515]

Proposed change

Handles an error that could occur on setting up the config entry when generating the entity_id slug from the name if the name from the GeoJSON feed was an int (not a str).

This was an unexpected regression from #108753 and should be included before the new release in order to avoid breaking the integration unexpectedly.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue:

Logger: homeassistant
Source: util/__init__.py:47
First occurred: 17:07:48 (3956 occurrences)
Last logged: 17:17:41

Error doing job: Task exception was never retrieved Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 658, in _async_add_entity
    entry = entity_registry.async_get_or_create(
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity_registry.py", line 661, in async_get_or_create
    entity_id = self.async_generate_entity_id(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity_registry.py", line 581, in async_generate_entity_id
    preferred_string = f"{domain}.{slugify(suggested_object_id)}"
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/__init__.py", line 47, in slugify
    slug = unicode_slug.slugify(text, separator=separator)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/slugify/slugify.py", line 104, in slugify
    text = _unicode(text, 'utf-8', 'ignore')
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: decoding to str: need a bytes-like object, int found

• This PR fixes issue: also addresses code quality comments from https://github.com/home-assistant/core/pull/108753/files/39a1c272560fadd8b77f2cbc9b6d18f9bf81f1a7#r1466299648
• This PR is related to issue: TypeError: decoding to str: need a bytes-like object, int found un33k/python-slugify#144
• This PR is related to PR: Use feed name as entity name in GeoJSON #108753

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the [development checklist][dev-checklist]
• I have followed the [perfect PR recommendations][perfect-pr]
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @exxamalte, mind taking a look at this pull request as it has been labeled with an integration (geo_json_events) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of geo_json_events can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign geo_json_events Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[exxamalte]

I was just thinking of an alternative where we enforce this type conversion to str in the underlying library?
https://github.com/exxamalte/python-aio-geojson-generic-client/blob/main/aio_geojson_generic_client/feed_entry.py#L26

[NasaGeek]

I was just thinking of an alternative where we enforce this type conversion to str in the underlying library? https://github.com/exxamalte/python-aio-geojson-generic-client/blob/main/aio_geojson_generic_client/feed_entry.py#L26

I think that would be a good change (especially considering that the lib already claims to return str), but since this PR is also working with the name property which the underlying library has no opinions about, there would still be necessary changes to handle that. Generally I do think that this PR shouldn't be concerned with the .title property.

[codyc1515]

I have done some further investigating. It turns out that the code which was causing this error (below):

core/homeassistant/util/__init__.py

Lines 43 to 48 in a793a54

	def slugify(text: str | None, *, separator: str = "_") -> str:
	"""Slugify a given text."""
	if text == "" or text is None:
	return ""
	slug = unicode_slug.slugify(text, separator=separator)
	return "unknown" if slug == "" else slug

Passes on any values from the entity name, including those names that are not str (as we are doing here with int), to the function unicode_slug.slugify. However, slugify does not, and will not, support any non-str values.

Should we not fix it at the root then (rather than in each integration)? Maybe I should raise a separate PR for that.

[codyc1515]

Closing in favour of #108989. Will re-open this if that one was not accepted.

[NasaGeek]

I think we were trending in right direction with this PR, as an entity's name property is expected to be a str (as indicated by the typing at

core/homeassistant/helpers/entity.py

Line 720 in a793a54

def name(self) -> str | UndefinedType | None:

). There could be other misbehavior we haven't yet encountered if we allow the name to remain an int and try to fix things downstream in the slugify call.

[codyc1515]

So what’s the proposal from here? All checks pass already and we handle the int scenario.

[codyc1515]

I have incorporated all of the feedback now.

[NasaGeek]

Thanks, @codyc1515! I'm happy where this ended up.

[codyc1515]

If this PR is not merged soon, 2024.2 release will be broken for some GeoJSON users.

[frenck]

Thanks, @codyc1515 👍

../Frenck