Skip to content

[codex] Reduce idle dev SQS polling#1

Merged
manynames3 merged 1 commit into
mainfrom
codex/reduce-dev-sqs-empty-receives
Jun 19, 2026
Merged

[codex] Reduce idle dev SQS polling#1
manynames3 merged 1 commit into
mainfrom
codex/reduce-dev-sqs-empty-receives

Conversation

@manynames3

Copy link
Copy Markdown
Owner

Summary

  • disable the Lambda SQS event source mapping by default in dev while preserving staging and production defaults
  • keep 20-second long polling on the processing queue and DLQ
  • add processor polling configuration logs and the NumberOfEmptyReceives dashboard metric
  • document intentional dev worker operation and CloudWatch verification
  • add Terraform plan tests and run them in CI

Root cause

The repository has no application-side SQS polling loop. The always-enabled Lambda event source mapping continuously polls grantstack-dev-processing while idle. Because AWS owns that polling loop, adding sleep or jitter inside the processor Lambda would not affect empty receives.

Impact

Dev messages remain queued until enable_sqs_worker = true is applied. Staging and production remain enabled by default. Queues, DLQs, partial batch failure behavior, and the existing 960-second visibility timeout are preserved.

Batch size remains one because a single report can use the processor's 900-second timeout.

Validation

  • terraform fmt -check -recursive
  • terraform validate
  • terraform test (3 passed)
  • Python compile checks
  • python3 -m unittest discover -s grantstack-backend/tests (19 passed)
  • git diff --check

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a mechanism to disable the SQS Lambda event source mapping by default in the development environment to prevent empty-receive charges, while keeping it enabled in staging and production. It includes updated documentation, runbooks, Terraform configuration, tests, and enhanced logging in the processor Lambda. A review comment suggests improving the robustness of the Lambda handler by safely handling cases where the input event or its 'Records' key is null, preventing potential TypeErrors.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

config = load_config()
table = dynamodb.Table(config.table_name)
failed_items: List[Dict[str, str]] = []
records = event.get("Records", [])

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If event is None or if the "Records" key is explicitly set to null (which parses as None in Python), calling event.get("Records", []) will return None. This will subsequently cause a TypeError when len(records) is evaluated on line 69, or a TypeError when iterating over records on line 72.

To make this more robust and adhere to defensive programming practices, use a guard to handle both None event and None records cases.

Suggested change
records = event.get("Records", [])
records = event.get("Records") or [] if event else []

@manynames3 manynames3 marked this pull request as ready for review June 19, 2026 22:58
@manynames3 manynames3 merged commit 363ca93 into main Jun 19, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant