inability to set timeout on a per-action basis

[tswaters]

I'm not sure if this belongs in seneca-transport, seneca-mesh or seneca-balance-client.

I ran into an issue where I was unable to set the timeout for a single action added to the mesh.... it's possible, but comes with a bit of a caveat in that the pin configuration in the seneca-mesh options needs to have a timeout.... this may not be ideal if using * to match multiple actions.

From reading through the seneca code, it should be possible to set timeout$ as part of the action payload to change the default timeout... while this works to increase the timeout of the gate executor, an invalid_origin message is logged and the role:transport,hook:listen in the error log shows its timeout is still the 5555.

It is possible to provide configuration options for an entire pinspec, e.g.:

seneca.use(SenecaMesh, {
 ...
  listen: [
    {pin: 'role:whatever,cmd:*', timeout: 999999}
  ]
}

And this correctly increases the timeout, but if you want it on a specific command, the pins need to be split out to not use * which may not be ideal.

It would be nice if a timeout$ defined in the act call was respected by seneca-transport or if a timeout$ could be defined on the action itself to indicate it'll take a bit longer than the default.

My use case is pulling images from s3, performing transformations and re-uploading the transformed images.... this can take a bit longer than the 5555 timeout and to get around it I had to update the timeout across the entire prior -- so web calls into entity, entity calls image - both entity and image needed an increased timeout in the mesh configuration; the web action was fine adding timeout$ to the act call. (this doesn't use seneca-web.... and, it should be noted there is no way to set timeout$ to a route mapped from seneca-web presently)

[rodmaz]

Have you found a solution to this? We actually attempted to use the timeout$ attribute in act but it still times out after 5555 ms.

[tswaters]

We stopped using mesh, switched to pins being explicitly defined - we're using the amqp transport.

I'm pretty sure defining timeout on the seneca-mesh pin as above, in addition to setting timeout$ on act worked, last I checked.

[rjrodger]

Thanks all - will investigate - timeout handling should be consistent