Closed xeger closed 2 years ago
Yup! Good bug report. When I added the Lambdakiq handler I failed to test it because I would have had to copy a few things over from the Lambdakiq gem. I was lazy... but did the work now in the #121 pull request. If those tests pass, I will do a tiny version bump and cut a new release. Again, thanks!!!
Pushed v3.1.2. Lemme know how that does for you.
Works like a charm; thank you so much for the quick response, @metaskills!
I found an unrelated minor SNAFU in lambdakiq; will file an issue there.
I'm using Lamby with a non-Rails Rack app. It's been working exceptionally well for me. I'm experimenting with lambakiq for background jobs and I've hit on a minor snag. I can easily monkey patch Lamby, but I wanted to give you a heads-up in case I'm doing something wrong.
The problem
When
Lamby::Handler#call_handler
instance method detects an SQS event, it doesn't return a proper Rack triple. This means that the handler's@body
becomes null when#call
assigns the return value to@status, @headers, @body
.Lamby::Handler.call
class method finishes by calling#response
on the handler instance, which assumes that@body
is non-nil. However, for Lambdakiq events, it's always nil!It seems like Lamby will therefore crash 100% of the time when
Lamby.handler
is used to dispatch the event. Am I missing something?The gory details
My handler
This is pretty vanilla; although I'm using Praxis, not Rails, my
$app
is still a Rack app and the handler is byte-for-byte identical to the Lambdakiq README.Backtrace + Lambda error report