search

noodlefrenzy / node-amqp10

amqp10 is a promise-based, AMQP 1.0 compliant node.js client
MIT License
134 stars 56 forks source link

Warning: a promise was rejected with a non-error: [object Object] #287

Open jeffmcaffer opened 7 years ago

jeffmcaffer commented 7 years ago

Running 3.4.0 I'm getting warnings (see title) dumped to the console reasonably consistently (when I get, for example size errors). This is coming from Bluebird. They have an explanation as to why they log the warning.

The root cause appears to be some code in sender_link (line 126). That is getting an error in the callback and then rejecting without checking that it is an error. See the end of the dump below for an example. I didn't track this down further. Not sure if this approach is intentional. While we can turn off the logging in Bluebird, that masks other problems. Would be great not to have console output under normal operating conditions (yes this only happens when there are errors but those are handled separately through other mechanisms)

Error: BLUEBIRD =======================
    at Promise._rejectCallback (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/bluebird/js/release/promise.js:468:14)
    at /home/ospo/ghcrawler/ospo-ghcrawler/node_modules/bluebird/js/release/promise.js:486:17
    at Object.deferredSender (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/sender_link.js:126:29)
    at SenderLink._dispositionReceived (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/sender_link.js:276:36)
    at dispositionHandler (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/session.js:459:44)
    at Array.forEach (native)
    at Session._processDispositionFrame (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/session.js:463:33)
    at Session._processFrame (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/session.js:305:66)
    at Connection._processFrameEH (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/session.js:186:49)
    at emitOne (events.js:101:20)
    at Connection.emit (events.js:188:7)
    at Connection._receiveAny (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/connection.js:426:12)
    at Connection._receiveData (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/connection.js:357:8)
    at TlsTransport.<anonymous> (/home/ospo/ghcrawler/ospo-ghcrawler/node_modules/amqp10/lib/connection.js:515:38)
    at emitOne (events.js:96:13)
    at TlsTransport.emit (events.js:188:7)
{ value:
   [ { [String: 'amqp:link:message-size-exceeded'] typeName: 'symbol', value: 'amqp:link:message-size-exceeded' },
     { [String: 'The received message (delivery-id:104, size:65504 bytes) exceeds the limit (51200 bytes) currently allowed on the link. TrackingId:52729a39-1c91-4a5a-8b16-d44e9aa0a18c_G5, SystemTracker:client-link6995513, Timestamp:1/15/2017 7:08:40 AM']
       typeName: 'string',
       value: 'The received message (delivery-id:104, size:65504 bytes) exceeds the limit (51200 bytes) currently allowed on the link. TrackingId:52729a39-1c91-4a5a-8b16-d44e9aa0a18c_G5, SystemTracker:client-link6995513, Timestamp:1/15/2017 7:08:40 AM' },
     ForcedType { typeName: 'fields', value: {} } ] }
(node:57992) Warning: a promise was rejected with a non-error: [object Object]
mbroadst commented 7 years ago

@jeffmcaffer this appears to be because you are receiving a protocol error off the link, but its somehow not being wrapped properly to inherit Error. I've never seen this before myself, are you able to easily reproduce this? Could you possibly run your example in debug mode (with DEBUG=amqp* as an environment variable) and paste the output here?

jeffmcaffer commented 7 years ago

I've not tried this directly but this problem appears (at least) when receiving a message that is larger than the configured size for the receiver_link. Some of our messages get pretty big (200K) but most are more like 1K. We can look at creating a repro unless you have some easy test harness to make this happen.

I got the above stack trace by hacking the Bluebird code to dump the stack at the point in the code where it detects the problem.