seneca: Global timeout not firing on 3.2.1

@mcdonnelldean Hi, guys! So, today @vigneshnrfs opened an issue over at seneca-amqp-transport explaining that his actions weren’t timeoutting using latest Seneca release 3.0.0, but were doing fine in 2.1.0. It turned out he was (is) absolutely right.

I investigated a little bit and found out that some work has been done on this. Like doubling the default timeout value. Has any of the API changed regarding this? Would you have any ideas on why no TIMEOUT errors are being thrown on Seneca 3.0.0? Maybe I need to update something on the transport logic?

Thanks!

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 28 (27 by maintainers)

Commits related to this issue

Most upvoted comments

@nfantone Good spot, I’ll have a look over this as soon as I can and see. There should be no api changes around this.

@nfantone just for clarity: I was checking seneca today and noticed that even if there’s no callback the timeout is still fired and that will trigger the generic “error” handler

client.error(function (err) {
     console.log(err)
})
 client.act('cmd:salute', { name: 'World' });

@nfantone sure, I’ll double check this

@nfantone I’ve submitted a PR with a possible solution to the problem, @rjrodger should review it.

About the inconsistent behaviour, I think it depends on how and when the action execution is inserted into the gate-executor. If this happen before start is called on the gate, or this is the first action the timeout will work correctly. Following actions won’t.

I’ve tested your use case on amqp with the updated gate-executor and it seems to work correctly. Let’s try it again when it is officially released.

I think this is a problem with the updated gate-executor not respecting timeouts, causing most of the actions in seneca to never timeout, see https://github.com/senecajs/gate-executor/issues/16