[Azure Event Hub]- Sending Event Message with Partition Key of type int is DANGEROUS

Hi, a few days ago I wrote script that sends the real time events to Event Hub. I used Azure Durable Functions to implement parallelism, and in doing so I used partition_key to ensure events with same id is directed to same partition. For some reason I thought the key can be single number and thus I used int types as partition keys, and while sending I never had any error about it. Later I implemented another function App that listens to Event Hub, and triggered when new message is received in Even Hub, and while doing so I was getting the following error at each firing: Unable to cast object of type 'System.Int32' to type 'System.String

At first I thought may be this is due to encoding of str files that send which took me quite a long time to figure out this was because my usage of int value as partition key due to which Event Hub backend could not generate partition key hashes.

I am wondering why no Exception is raised if int type is passed as partition_key argument at the time of sending message string, and may be this is bug to be considered.

[serkantkaraca]

@YijunXieMS service ignores partition-key if it is not string type.

[jsquire]

Thank you, @aliyevmirzakhan.

Based on that, I think @johanste’s initial assessment is likely. The Azure Functions infrastructure is based on .NET and the bindings are running in the context of that infrastructure using the .NET Event Hubs client rather than running in the context of the Python language worker and using the Python SDK.

The root cause would appear to be that the partition key is enforced as string by the Track One and Track Two client libraries for all languages other than Python. The question, in my opinion, comes down to “should we guarantee that events published from a language can be read by the other languages and across versions of the SDK?”

Assuming so, I believe the choice comes down to:

• Do we investigate whether there is a way to be looser with type checking and coerce non-string values to string in the non-Python libraries?
• Do we introduce a breaking change to the Python library to validate the type matches the documentation?
• Do we leave the Python behavior as-is and consider a stronger warning in documentation about cross-language compatibility?
• Do we introduce breaking changes to the other libraries to allow a generic object value and, if so, does that include the track one libraries as well?

As @ramya-rao-a mentions, so long as the service team does not have a service-specific reason to disallow, the first is probably our most promising starting point. The tricky part of that will be that the Azure Functions bindings are still using the track one Event Hubs client.