Azure / Azure/azure-iot-hub-node

"Maximum call stack size exceeded" during repeated AMQP reconnects

Open
#61 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.