Conversation
|
Tested on 2.7 and 3.6. Relevant configuration: |
|
Running great on several of my 3.6 functions that use a 2-stage zappa function for webhooks with bursty traffic (one public-facing to persist JSON to an SQS queue with a variable message timer to smooth out the traffic, one private-facing to process them into another API or database). This PR eliminates most of our empty receives and SQS polling code 🍾 |
|
Any way you can squash these commits? |
| "event_source": { | ||
| "arn": "arn:aws:sqs:us-east-1:12341234:your-queue-name-arn", | ||
| "batch_size": 10, // Max: 10. Use 1 to trigger immediate processing | ||
| "enabled": true // Default is false |
There was a problem hiding this comment.
Why is this needed? We don't have an enabled field for other event sources. If they are present, they are enabled.
There was a problem hiding this comment.
Probably isn't going to test without it and clean up if it works.
There was a problem hiding this comment.
Strangely, none of the event sources have the 'enabled' knob built into the AWS configuration. See 'Enabled' parameter at end of documentation: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
I suspect it's probably some sort of throttling mechanism that typical SQS event sinks have control over. Agree that it's a little wonky, but I would recommend to leave it.
There was a problem hiding this comment.
@mcrowson enabled is false by default on push events - we also have the same behaviour for the other push events (dynamodb and kinesis). Without enabled you need to turn it on in the console, which makes some sense to me if you want to control/test when a consumer is "consuming" information from a queue.
| ## Executing in Response to AWS Events | ||
|
|
||
| Similarly, you can have your functions execute in response to events that happen in the AWS ecosystem, such as S3 uploads, DynamoDB entries, Kinesis streams, and SNS messages. | ||
| Similarly, you can have your functions execute in response to events that happen in the AWS ecosystem, such as S3 uploads, DynamoDB entries, Kinesis streams, SNS messages, and SQS queues. |
There was a problem hiding this comment.
Do we need to update the default IAM stuff to include SQS perms?
There was a problem hiding this comment.
No, it's a push event.
|
The easiest way would be doing it on merge.On 1 Oct 2018 15:42, MCrowson <notifications@github.com> wrote:Any way you can squash these commits?
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.
|
Fixes: #1613
Description
Adds support to SQS events.
This version uses an event source based on kappa. It should be removed if garnaat/kappa#133 is merged in kappa.
GitHub Issues
#1613