Closed nbigaouette-eai closed 5 years ago
hi @nbigaouette-eai I just ran into the same issue. You're likely to see this issue still today but for different reasons but they are issues on the serverless side.
I ran into this issue while trying to implement invoke local for the serverless-rust plugin https://github.com/softprops/serverless-rust/issues/9#issuecomment-420153191 which led me to an interesting find https://github.com/serverless/serverless/issues/5283#issuecomment-420510817 and a follow up pr in serverless proper to address https://github.com/serverless/serverless/pull/5291
If this gets merged in serverless, you ( and me both ) should be in ship shape. In the mean time it may be worth closing this issue on the crowbar side. Crowbars implementation actually represents more faithfully the context you'll be interactive with inside of aws's runtime
My pull request to the serverless framework was merged and should be in it's next release. I confirmed with a local clone invoke local now works. I think you can close this @ilianaw :)
Nice! (Can you link the pull request?)
Linked above https://github.com/serverless/serverless/pull/5291
Just dropping a note for record keeping. This serverless patch was in the release yesterday https://github.com/serverless/serverless/releases/tag/v1.33.0 ( after 2 months! )
I'm trying to invoke
sls invoke local
on the built lambda (with crobar v0.2.0) but I am having issues doing so.It seems that the problem comes from
string_storage
when creating theLambdaContext
.Errors are kind of cryptic:
After some investigation, the
TypeError
seems to come from thecontext
handling inside crowbar. For example, setting thecontext
(in serverless' invoke.py file) to a dictionary of strings for the differentstr_attr!()
values gives me:From the serverless' invoke.py file, it seems that the expected attributes are
@property
s. Maybe that is what is confusing crowbar?Thanks for the crate by the way ;)