IoT Hub – Workaround for "Maximum call stack size exceeded"

Question

IoT Hub – Workaround for "Maximum call stack size exceeded"

Nelson Lim 0

The Background

Our production application has been experiencing intermittent connection issues with Azure IoT Hub. To investigate the problem, I performed a load test to reproduce the behavior.

During the test, the application sent approximately 2,000 Cloud-to-Device (C2D) messages to Azure IoT Hub using the Node.js azure-iothub SDK over AMQP (port 5671).

While messages were being sent, outbound traffic on port 5671 was intentionally blocked. This caused all AMQP connections to fail, leaving a large number of send operations pending. After the port was briefly restored, the SDK attempted to reconnect and resume the pending sends. Shortly afterward, the port was blocked again, forcing the SDK into another recovery cycle while many send operations were still outstanding.

During this repeated disconnect/reconnect sequence, the SDK eventually threw the following exception:

RangeError: Maximum call stack size exceeded

The stack trace indicates that the exception originated from the SDK's internal getErrorName() function, suggesting that the failure occurred while processing an error object rather than during the actual send operation. This appears to indicate that the SDK entered an unexpected recursive error-handling path during connection recovery. Based on these observations, this appears to be an SDK-level issue rather than an application logic issue.

Impact

This exception is uncaught by the SDK and causes the entire Node.js application to crash. The application can only recover after it is restarted, making this a critical production issue.

Additional Information

SDK: azure-iothub (tested with v1.16.6 latest)
Transport: AMQP (port 5671)
Message Type: Cloud-to-Device (C2D)
Reproduction: Consistently reproducible by repeatedly blocking and restoring AMQP connectivity while a large number of send operations are in progress.

Has anyone encountered this issue before, or is there a recommended workaround to prevent the SDK from entering this state during connection recovery?

Vinodh247-1375 43,586 Reputation points Volunteer Moderator

2026-07-29T04:30:31.4166667+00:00
Please confirm if you had a chance to try any of the suggestions provided for your question.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful.

If in case you have any resolution please share the same here with the community as it can be helpful to others. Else, please respond with more details and we will try to see if we can help further.

1 answer

Your answer

Vinodh247-1375 43,586 Reputation points Volunteer Moderator

2026-07-29T04:30:31.4166667+00:00

Please confirm if you had a chance to try any of the suggestions provided for your question.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful.

If in case you have any resolution please share the same here with the community as it can be helpful to others. Else, please respond with more details and we will try to see if we can help further.

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

This is a known failure pattern under heavy pending operations+unstable AMQP where the Node.js azure-iothub SDK can get into recursive error handling during reconnect storms. There is no clean bypass, so the practical workaround is to control concurrency and failure behaviour: throttle C2D sends (queue with max inflight limit instead of blasting 2K async calls), implement retry with exponential backoff+jitter outside the SDK, and cancel/timeout pending sends when the connection drops rather than letting them pile up. Also consider switching transport to AMQP over websockets (443) to avoid port blocks, and add a process level guard (uncaughtException handler+graceful restart) to prevent full crashes. If possible, upgrade or test alternate patterns (Service Bus queue ->device pull) since C2D at that scale with flaky connectivity is fragile in this SDK.

Two key questions?

Are you firing all 2k sends concurrently or using any bounded queue/backpressure mechanism?
Have you tested AMQP over websockets or reduced retry policy to limit recursive reconnect attempts?

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

ADM Nelson Lim 0 Reputation points

2026-07-29T06:28:10.65+00:00

Hi,

Two key answers:

During my load test, I sent 2,000 messages concurrently. However, I also tested by sending only 2 or 10 messages concurrently, and I encountered the same error.

Yes, I'm using AMQP with the default retry policy. I tried reducing the retry count and disabled the retry, which helped reduce the frequency of the error, but it still occurred.