Azure / Azure/azure-iot-hub-node
"Maximum call stack size exceeded" during repeated AMQP reconnects
- Dominant language
- TypeScript
- Stars
- 3
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
**Summary**
The production application has been experiencing intermittent connection issues with Azure IoT Hub. During investigation, a load test was performed to reproduce the behavior, and a reproducible issue was identified in the Node.js azure-iothub SDK.
**Environment**
SDK: `azure-iothub` v1.16.6 (latest)
Transport: AMQP (port 5671)
Message Type: Cloud-to-Device (C2D)
Runtime: Node.js
**Reproduction Steps**
1. Start sending approximately 50 Cloud-to-Device (C2D) messages to Azure IoT Hub using the Node.js `azure-iothub` SDK over AMQP.
2. While messages are actively being sent, block outbound traffic on port 5671.
3. Wait until a large number of send operations accumulate.
4. Restore network connectivity briefly, allowing the SDK to reconnect and begin processing pending messages (around 3~4 seconds).
5. Block port 5671 again before all pending operations have completed.
6. Repeat the disconnect/reconnect cycle.
**Expected Behavior**
- The SDK should recover from intermittent network interruptions.
- Pending send operations should resume successfully after reconnection.
**Actual Behavior**
After several disconnect/reconnect cycles while many send operations are still pending, the SDK eventually throws the following exception:
```
{
"type": "RangeError",
"message": "Maximum call stack size exceeded",
"stack":
RangeError: Maximum call stack size exceeded
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:147:3)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
at getErrorName (C:\Git\middleware-agent-cloud\node_modules\azure-iothub\src\common-amqp\amqp_common_errors.ts:153:26)
}
```
The stack trace indicates that the exception originates from the SDK's internal getErrorName() function, suggesting that the failure occurs while processing an error object rather than during the send operation itself.
This appears to indicate that the SDK enters an unexpected recursive error-handling path during connection recovery.
**Impact**
The exception is uncaught by the SDK.
The entire Node.js process crashes.
The application cannot recover automatically and requires a full restart.
This is a critical production issue because intermittent Azure IoT Hub connectivity can cause prolonged service disruption.
**Additional Notes**
The exception can be caught via the Node.js uncaughtException handler, preventing the application from terminating immediately. However, the Azure IoT Hub client becomes unusable after the exception, and sending operations cannot resume unless the client is reinitialized (or the application is restarted).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with src/common-amqp/amqp_common_errors.ts and inspect getErrorName(), which appears repeatedly in the reported stack trace. Reproduce the issue with the described load test, repeated AMQP disconnects on port 5671, and pending C2D sends. Done means repeated reconnect cycles no longer cause recursive error handling or an uncaught exception, and pending sends can resume without reinitializing the client.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, node.js, typescript
- Domain
- api, backend, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100