Conversation
📝 WalkthroughWalkthroughLocalStack image versions updated across docker-compose files (4.10.0→4.13.1 and 4.0.2→4.13.1), and SQS message size limits increased from 256 KB to 1 MiB in code constants and documentation to align with the new threshold. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/sqs/lib/sqs/AbstractSqsService.ts`:
- Around line 11-12: You exported SQS_MESSAGE_MAX_SIZE (now 1 MiB) which is a
behavioral breaking change for consumers who derived maxPayloadSize from it—add
a clear changelog entry and migration note and either (A) publish this change as
a semver-major release or (B) re-introduce a backwards-compatible alias like a
deprecated SQS_LEGACY_MAX_SIZE = 256 * 1024 and document preferred usage; update
the package release notes (and packages/sqs/lib/index.ts re-export) to call out
the change, recommended migration steps for consumers using
payloadStoreConfig.maxPayloadSize, and which symbol (SQS_MESSAGE_MAX_SIZE vs
SQS_LEGACY_MAX_SIZE) they should use going forward.
- Around line 11-12: The SQS_MESSAGE_MAX_SIZE constant declares the SQS service
limit (1 MiB) but the pinned `@aws-sdk/client-sqs` may still enforce the older 256
KiB client-side validator; either upgrade the SDK to a version that includes the
1 MiB validator (>= 3.990.0) or explicitly document the mismatch where
SQS_MESSAGE_MAX_SIZE is defined in AbstractSqsService.ts so callers know the SDK
may reject MessageBody >256 KiB; update package.json dependency for
`@aws-sdk/client-sqs` to >=3.990.0 and/or add a comment next to
SQS_MESSAGE_MAX_SIZE clarifying it reflects the service limit not the SDK
validator limit.
In `@packages/sqs/README.md`:
- Line 383: The inline comment on MaximumMessageSize is ambiguous; update the
comment next to the MaximumMessageSize attribute to state that '1048576' is the
new maximum allowed per-message size (1 MiB) rather than a changed default, and
clarify that leaving the attribute unset preserves the previous default (262144
bytes) while explicitly setting MaximumMessageSize: '1048576' opts the queue
into the larger cap; reference the MaximumMessageSize attribute in the README to
make this distinction explicit.
| // https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html | ||
| export const SQS_MESSAGE_MAX_SIZE = 256 * 1024 // 256KB | ||
| export const SQS_MESSAGE_MAX_SIZE = 1024 * 1024 // 1 MiB |
There was a problem hiding this comment.
SQS_MESSAGE_MAX_SIZE is a publicly exported constant — this is a behavioral breaking change that needs a changelog entry.
SQS_MESSAGE_MAX_SIZE is re-exported from packages/sqs/lib/index.ts. Any consumer who derived their maxPayloadSize from this constant (e.g., payloadStoreConfig: { maxPayloadSize: SQS_MESSAGE_MAX_SIZE }) will now silently skip S3 offloading for messages between 256 KiB and 1 MiB. Infrastructure relying on those messages flowing through S3 (lifecycle policies, monitoring, auditing) could be affected. A semver-major bump or explicit migration note in the changelog is warranted.
Amazon SQS increased the maximum message payload size from 256 KiB to 1 MiB for standard and FIFO queues, so the constant value itself is correct.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/sqs/lib/sqs/AbstractSqsService.ts` around lines 11 - 12, You
exported SQS_MESSAGE_MAX_SIZE (now 1 MiB) which is a behavioral breaking change
for consumers who derived maxPayloadSize from it—add a clear changelog entry and
migration note and either (A) publish this change as a semver-major release or
(B) re-introduce a backwards-compatible alias like a deprecated
SQS_LEGACY_MAX_SIZE = 256 * 1024 and document preferred usage; update the
package release notes (and packages/sqs/lib/index.ts re-export) to call out the
change, recommended migration steps for consumers using
payloadStoreConfig.maxPayloadSize, and which symbol (SQS_MESSAGE_MAX_SIZE vs
SQS_LEGACY_MAX_SIZE) they should use going forward.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify the `@aws-sdk/client-sqs` version in use and check for large-message tests.
# 1. Show declared version across all package.json files (excluding node_modules)
echo "=== Declared `@aws-sdk/client-sqs` version ==="
fd 'package.json' --type f | xargs grep '"@aws-sdk/client-sqs"' 2>/dev/null
# 2. Check if any test or source files exercise message sizes near/above 262144 bytes
echo -e "\n=== Large-message test/usage references ==="
rg -n --type ts -C 3 'SQS_MESSAGE_MAX_SIZE|262144|1048576|maxPayloadSize'Repository: kibertoad/message-queue-toolkit
Length of output: 6192
🏁 Script executed:
#!/bin/bash
# Check how payload offloading handles large messages and look for validator constraints
# 1. Look at payload offloading implementation
echo "=== Payload offloading implementation ==="
fd 'payloadOffloa' --type ts | head -5 | xargs -I {} bash -c 'echo "File: {}"; head -50 {}'
# 2. Search for test message creation to see if large messages are actually sent
echo -e "\n=== Test message creation in payload offloading tests ==="
rg -A 10 'describe.*payload offloading' packages/sqs/test/consumers/SqsPermissionConsumer.payloadOffloading.spec.ts | head -30Repository: kibertoad/message-queue-toolkit
Length of output: 1332
🌐 Web query:
@aws-sdk/client-sqs 3.812.0 validator maxLength 262144 SQS 1 MiB limit when updated
💡 Result:
Amazon SQS raised the maximum message payload size to 1,048,576 bytes (1 MiB) on August 4, 2025 (from 256 KiB). [1] The SQS quotas/docs now state “Message size … maximum is 1,048,576 bytes (1 MiB)”, and the FAQ likewise says MaximumMessageSize can be set up to 1 MiB. [2][3]
So if @aws-sdk/client-sqs@3.812.0 is still enforcing a maxLength: 262144 validator, that limit reflects the old 256 KiB (262,144 bytes) model and the SDK’s generated validation metadata hasn’t caught up to the service change yet.
When will the SDK update? I couldn’t find any AWS-published date/commit guaranteeing when @aws-sdk/client-sqs will change that validator; as of today (Feb 20, 2026), the authoritative service limit is already 1 MiB in AWS docs, but the SDK-side validator may still be outdated. [2][3]
Practical implication: SQS can accept up to 1 MiB (subject to the queue’s MaximumMessageSize), but the JS v3 client may block >262,144-byte MessageBody locally until the model/validator is updated (or you bypass/patch that validation). [2][3]
Sources
[1] Amazon SQS “What’s New” announcement (Aug 4, 2025)
[2] SQS Developer Guide – message quotas (Message size max 1,048,576 bytes)
[3] SQS FAQ – configuring MaximumMessageSize up to 1 MiB
🏁 Script executed:
#!/bin/bash
# Look at the actual test to see message sizes being tested
echo "=== Test file content (first 150 lines) ==="
cat -n packages/sqs/test/consumers/SqsPermissionConsumer.payloadOffloading.spec.ts | head -150Repository: kibertoad/message-queue-toolkit
Length of output: 6846
Upgrade @aws-sdk/client-sqs to 3.990.0 or verify the version includes the 1 MiB validator.
The project pins @aws-sdk/client-sqs@3.812.0, which may still enforce a client-side validation limit of 262,144 bytes for MessageBody (the pre-August 2025 limit). AWS announced the 1 MiB limit increase on August 4, 2025, but the SDK's Smithy-generated validators lag behind the service model update. The current tests work because they use S3 payload offloading—only sending a small pointer message to SQS—rather than testing direct 1 MiB message sends.
If any code attempts to send a MessageBody between 256 KiB and 1 MiB directly to SQS without offloading, the client-side validator will reject it before the request reaches AWS. Either upgrade the SDK to a version released after the service model was updated, or document that SQS_MESSAGE_MAX_SIZE represents the SQS service limit, not the SDK's validator limit for direct messages.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/sqs/lib/sqs/AbstractSqsService.ts` around lines 11 - 12, The
SQS_MESSAGE_MAX_SIZE constant declares the SQS service limit (1 MiB) but the
pinned `@aws-sdk/client-sqs` may still enforce the older 256 KiB client-side
validator; either upgrade the SDK to a version that includes the 1 MiB validator
(>= 3.990.0) or explicitly document the mismatch where SQS_MESSAGE_MAX_SIZE is
defined in AbstractSqsService.ts so callers know the SDK may reject MessageBody
>256 KiB; update package.json dependency for `@aws-sdk/client-sqs` to >=3.990.0
and/or add a comment next to SQS_MESSAGE_MAX_SIZE clarifying it reflects the
service limit not the SDK validator limit.
| // Other attributes | ||
| DelaySeconds: '0', // Default delay for all messages | ||
| MaximumMessageSize: '262144', // 256 KB (default maximum) | ||
| MaximumMessageSize: '1048576', // 1 MiB (default maximum) |
There was a problem hiding this comment.
// 1 MiB (default maximum) is ambiguous — clarify whether this is the new per-queue default or just the new maximum allowed value.
The MaximumMessageSize queue attribute previously defaulted to 262,144 bytes (256 KiB). If you've explicitly set the MaximumMessageSize attribute, you might need to adjust it to a new desired value. This wording implies the default was not automatically raised to 1 MiB — only the maximum ceiling was. If that's the case, setting MaximumMessageSize: '1048576' here doesn't represent the default but rather explicitly opts into the new maximum.
📝 Suggested comment clarification
- MaximumMessageSize: '1048576', // 1 MiB (default maximum)
+ MaximumMessageSize: '1048576', // 1 MiB (new maximum; set explicitly to opt in)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| MaximumMessageSize: '1048576', // 1 MiB (default maximum) | |
| MaximumMessageSize: '1048576', // 1 MiB (new maximum; set explicitly to opt in) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/sqs/README.md` at line 383, The inline comment on MaximumMessageSize
is ambiguous; update the comment next to the MaximumMessageSize attribute to
state that '1048576' is the new maximum allowed per-message size (1 MiB) rather
than a changed default, and clarify that leaving the attribute unset preserves
the previous default (262144 bytes) while explicitly setting MaximumMessageSize:
'1048576' opts the queue into the larger cap; reference the MaximumMessageSize
attribute in the README to make this distinction explicit.
1 participant
See https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html, new limit is 1 MB
Summary by CodeRabbit
Chores
Documentation