Invalid type NoneType for attribute 'http.port' value.

[mplemay]

Description

After upgrading to 2.11.1 from 2.11.0, I get a deluge of warnings (see below). For context, if I do not configure logfire I do not get any warnings. My logfire configuration is as follows:

logfire.configure(
    send_to_logfire="if-token-present",
    token=(None if SETTINGS.LOGFIRE_API_KEY is None else SETTINGS.LOGFIRE_API_KEY.get_secret_value()),
    console=(None if SETTINGS.DEBUG else False),
)

Invalid type NoneType for attribute 'http.port' value. Expected one of ['bool', 'str', 'bytes', 'int', 'float'] or a sequence of those types
Invalid type NoneType for attribute 'http.port' value. Expected one of ['bool', 'str', 'bytes', 'int', 'float'] or a sequence of those types
...

Python, Logfire & OS Versions, related packages (not required)

logfire="2.11.1"
platform="macOS-15.2-arm64-arm-64bit"
python="3.12.8 (main, Dec  3 2024, 18:42:41) [Clang 16.0.0 (clang-1600.0.26.4)]"
[related_packages]
requests="2.32.3"
pydantic="2.10.4"
fastapi="0.115.6"
openai="1.58.1"
protobuf="5.29.2"
rich="13.9.4"
executing="2.1.0"
opentelemetry-api="1.29.0"
opentelemetry-exporter-otlp-proto-common="1.29.0"
opentelemetry-exporter-otlp-proto-http="1.29.0"
opentelemetry-instrumentation="0.50b0"
opentelemetry-instrumentation-aiohttp-client="0.50b0"
opentelemetry-instrumentation-asgi="0.50b0"
opentelemetry-instrumentation-fastapi="0.50b0"
opentelemetry-instrumentation-sqlalchemy="0.50b0"
opentelemetry-proto="1.29.0"
opentelemetry-sdk="1.29.0"
opentelemetry-semantic-conventions="0.50b0"
opentelemetry-util-http="0.50b0"

[Kludex]

Hmm... That bump doesn't seem that would have changed that... Do you define "http.port" somewhere in your code? I can't find it on the integrations.

[mplemay]

Hey @Kludex , thanks for the quick reply. There may be a reference to "http.port" deep in a openai, fastapi, call but I do not explicitly define it. I did a quick search online and at first glance it seem like it may be an opentelemetry issue (see googleapis/python-bigquery#1140).

[alexmojaki]

If this is happening locally, try adding a breakpoint here:

https://github.com/open-telemetry/opentelemetry-python/blob/29aad2efa30a35757ea78d90e4d3fd517bc00468/opentelemetry-api/src/opentelemetry/attributes/__init__.py#L100-L106

[mplemay]

@alexmojaki Below is a snapshot of my debugging output

[Kludex]

Seesm to be a problem here:

https://github.com/microsoft/kiota-python/blob/ac46dd6f566581364fe470262508ef71b5c5cc53/packages/http/httpx/kiota_http/httpx_request_adapter.py#L604

The http.port should only be set if url.port is not None.

[mplemay]

That makes total sense and I will attempt to reach out to the folks at microsoft for a fix. With that being said, is there any reason why the warning just surfaced with the most recent version of logfire? And is there a way to get logfire to ignore these faulty opentelemetry calls?

[Kludex]

With that being said, is there any reason why the warning just surfaced with the most recent version of logfire?

I don't see how that's happening. Are you 100% about it?

And is there a way to get logfire to ignore these faulty opentelemetry calls?

That's really on opentelemetry's side. What you can do is get that internal logger and change the logger level, so it doesn't log warnings, or remove the handlers, or... But if it's not much of an issue, I recommend that you don't do anything and wait for the fix on kiota-python's side.

[alexmojaki]

We're planning on making all spans (including those produced by OTEL and third-party instrumentations) into 'logfire spans' which means that they will support arbitrary attribute value types, including None. Then the warning will go away by itself.

[mplemay]

I don't see how that's happening. Are you 100% about it?

I decently confident, but not 100% sure. I noticed the issue when I updated only logfire - so it may have happened beforehand. Either way @Kludex , I wouldn't put any though into it since it will get sorted out on Microsoft's end, it will be fixed by it becoming a logfire span (as per @alexmojaki 's comment), or I can just ignore it by changing the log level.

Thanks to the both of you for all of your help.

[Kludex]

Sounds good! :)