Trap handler in Worker calls logger (and other things) from trap context.

[glennpratt]

By configuring the WorkerOptions logger with a logger at level DEBUG:

aws_flow_defaults = AWSFlowDefaults.new(@logger)
AWS::Flow::WorkerOptions.default_classes << aws_flow_defaults

I see the logger being called from trap context:

Polling for a new activity task of type ["AcquiaCloudData.schema_create 1.0", "AcquiaCloudData.schema_delete 1.0"] on task_list: AcquiaCloudData
^Clog writing failed. can't be called from trap context
log writing failed. can't be called from trap context
log writing failed. can't be called from trap context
log writing failed. can't be called from trap context
log writing failed. can't be called from trap context
log writing failed. can't be called from trap context
1193 exited
1192 exited

It looks like the trap handler calls shutdown directly:

https://github.com/aws/aws-flow-ruby/blob/3e116d59e25a2e585117811d5bbb3e40f8b3e11e/aws-flow/lib/aws/decider/worker.rb#L47-L57

https://github.com/aws/aws-flow-ruby/blob/3e116d59e25a2e585117811d5bbb3e40f8b3e11e/aws-flow/lib/aws/decider/executor.rb#L87-L115

I'm not super familiar, but I would have the trap set a flag var or send something over a pipe or queue to the main loop and avoid doing any work, logging, etc.

[mjsteger]

The fix for this is, as you suggest, to set a flag variable and deal with the logging outside the trap context(like so). I've made a pull request which in part addresses this problem here: #105. In the meantime you can apply the same fix to your own fork or use mine.