Documentation
¶
Overview ¶
Command webhook-worker delivers the outgoing webhooks the auth function enqueued (D9b).
The auth function's WebhookDeliverer (internal/integration/aws, SQSWebhookDeliverer) puts each fully built, signed, numbered attempt on an SQS queue and returns once SQS has stored it; this Lambda, on that queue's event source with ReportBatchItemFailures, POSTs it to the receiver, retries it on the reference's schedule by setting the message's visibility, and hands it to the dead-letter queue when the subscription's attempts are spent. worker.go carries the per-record logic and the argument for each decision; this file reads the environment and starts the handler.
It is a separate binary and a separate artifact (dist/webhook-worker-*.zip) because it needs none of the auth function: no configuration document, no signing secret, no route, and IAM on exactly four things — receive, delete and change the visibility of messages on the webhook queue, send to the DLQ, the ledger partition of the table, and its own log group. The role is written out in the template (WebhookWorkerRole) rather than generated, because a generated role on an SQS event source also gets the managed AWSLambdaSQSQueueExecutionRole, which reaches every queue in the account. A compromised worker can POST what is already on the queue and nothing else.
Environment ¶
AWESOME_AUTH_WEBHOOK_QUEUE_URL the webhook queue (for ChangeMessageVisibility) AWESOME_AUTH_WEBHOOK_DLQ_URL the dead-letter queue AWESOME_AUTH_WEBHOOK_MAX_RECEIVE_COUNT the queue's RedrivePolicy.maxReceiveCount AWESOME_AUTH_WEBHOOK_QUEUE_RETENTION_SECONDS the queue's MessageRetentionPeriod AWESOME_AUTH_STORES_CONNECTION_TABLE_NAME the table holding the delivery ledger AWESOME_AUTH_STORES_CONNECTION_ENDPOINT optional: DynamoDB Local, for development
All but the last are required and a missing one fails the init, which the Lambda service reports and retries — better than a worker that acknowledges every message it cannot handle.
Source Files