String collections in trigger metadata may contain nulls, objects, arrays, numbers and strings after conversion

[boomlinde]

We noticed this in the messageIdArray field of a TriggerMetadata of a service bus message batch. String collections may actually contain numbers.

After a thorough search, the culprit seems to be in azure-functions-nodejs-library/src/converters/fromRpcTypedData.ts

In the fromRpcTypedData function, instead of simply returning data.collectionString.string, data.collectionString.string.map(tryJsonParse) is returned:

    } else if (data.collectionString && isDefined(data.collectionString.string)) {
        return data.collectionString.string.map(tryJsonParse);

What does tryJsonParse do?

function tryJsonParse(data: string): unknown {
    try {
        return JSON.parse(data);
    } catch {
        return data;
    }
}

So if a string ID is json-like, the json-like value is parsed and returned. Consequently, strings like "123" that are JSON-like will be converted as though they were JSON. In our case, IDs sometimes look like integers.

To add to the injury, if the string is JSON-object-like, the code will convert the keys to camel case. So if my message ID is the string '{"BafflingConversion": true}', fromRpcTypedData will convert it to the object {bafflingConversion: true}.

This issue was introduced in efa5fb3. There is of course no obvious, sane and logical reason that the entries of a string collection should ever be considered as or converted to JSON, and whatever insane circumstance prompted the change isn't clear from the commit message.

@ejizba can you add some context as to why string collections should ever be considered as JSON? What was the intended purpose of the change?

[swapnil-nagar]

@boomlinde

Thank you for providing the detailed context and flagging this concerning issue with the Service Bus batch scenario. Your analysis is spot-on.

Why This Behavior Was Introduced
I can hypothesize that behavior was introduced to handle automatic deserialization of JSON-encoded data that comes through the RPC layer as strings. In many Azure Functions scenarios, complex data structures need to be JSON-serialized when transmitted, and this change was introduced to automatically deserialize them back to their original types.

However, this creates the problem you've identified: semantic strings (like Service Bus message IDs) that happen to be JSON-parseable get unintentionally converted when they should remain as strings. This is particularly problematic for scenarios like yours where:

Recommended Solution

Given the challenges with the current behavior and my reluctance to make any changes in the librar(to avoid the impact on customers), I'd recommend migrating your Service Bus batch scenario to our newer Service Bus extension library. This library is specifically designed to optimize batching for Service Bus messages and gives you much more control over message handling.

https://github.com/Azure/azure-functions-nodejs-extensions/tree/main/azure-functions-nodejs-extensions-servicebus/samples

Key benefits for your use case:

• Preserves raw message data: Returns binary messages with helper methods to parse only when/how you need
• No automatic JSON conversion: You maintain full control over how strings are interpreted
• Better batch handling: Optimized specifically for Service Bus batch scenarios
• Partial failure support: Handle individual message failures within a batch
• You can learn more about this approach and see implementation examples here:
• [Take Control of Every Message: Partial Failure Handling for Service Bus Triggers] https://techcommunity.microsoft.com/blog/appsonazureblog/take-control-of-every-message-partial-failure-handling-for-service-bus-triggers-/4504893

Could you take a look at the extension library approach and let us know if this would resolve your scenario? If you have any feedback or run into issues during migration, please don't hesitate to reach out we'd love to hear about your experience and help ensure this works well for your use case.

[boomlinde]

Given the challenges with the current behavior and my reluctance to make any changes in the librar(to avoid the impact on customers)

I understand that bugs and features become practically indistinguishable when there's little documentation, no specification and the only contract you seem to have with users is a couple of examples and the observable behavior of the software, but you can address this from your end without breaking software that now depends on the broken behavior.

You could document the behavior up-front so that consumers of the library know not to expect it to work properly, and very visibly link to the currently preferred and supposedly functioning extension library. You could make the opportunistic JSON parsing optional, documenting how to turn it on or off.

This should not be a no-action issue.

Could you take a look at the extension library approach and let us know if this would resolve your scenario?

We have used this library as-is in production for some time now, and this bug only surprised us recently because a generated ID happened to look like a number.

From my perspective, the library has a fundamental flaw that I now know about and and can thankfully easily work around for my client's use case. That seems safer to use than another Azure library which for the generally poor state of specification and documentation in the Azure ecosystem likely has some other fundamental flaw that I don't know about which will suprise me later down the line.

Thanks for the offer to help, but consider this as a bug report more than a general request for assistance.