Bump sqs-consumer from 13.0.0 to 14.0.0

[dependabot]

Bumps sqs-consumer from 13.0.0 to 14.0.0.

Release notes

Sourced from sqs-consumer's releases.

v14.0.0

14.0.0 (2025-09-15)

SQS Consumer v14.0.0 Migration Guide

Overview

Version 14.0.0 introduces a breaking change to how message acknowledgment works. This change makes acknowledgment behavior more explicit and predictable, addressing user confusion about when messages are acknowledged.

What Changed

Previous Behavior (<=v13.x)

• Messages were acknowledged automatically in certain scenarios
• Returning void (nothing) from handlers had implicit acknowledgment behavior
• Users were often unclear about when messages would be acknowledged

New Behavior (>=v14.0)

• Explicit acknowledgment only: Messages are acknowledged only when explicitly returned
• Returning void (nothing) means no acknowledgment by default
• Clear, predictable behavior based on what your handler returns

Benefits of the New Approach

• Clarity: Explicit acknowledgment makes code intent clear
• Reliability: Reduce accidental acknowledgment of failed processing
• Debugging: Easier to trace acknowledgment behavior
• Flexibility: Fine-grained control over which messages are acknowledged

Migration Steps

handleMessage()

Step 1: Identify Your Current Handler Pattern

First, determine which pattern your current message handlers follow:

// Pattern A: Handler that processes and implicitly acknowledges
const handleMessage = async (message) => {
  await processMessage(message);
  // No explicit return - was implicitly acknowledged in v13.x
};
// Pattern B: Handler with conditional acknowledgment
const handleMessage = async (message) => {
const success = await processMessage(message);
if (success) {
return message; // Only acknowledge on success
</tr></table>

... (truncated)

Commits

• 7ed8218 chore: adjusting docs
• b253837 breaking: making acknowledgement explict
• 5bfb740 feat(breaking): do not acknowledge if void is returned (#583)
• c4729b4 fix: set specific node version for now
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[kibertoad]

@CarlosGamero I'm suspicious about this being automerged. I don't think we do the explicit acknowledgement the way it is described in release notes?..

[CarlosGamero]

@kibertoad Yeah, I’m not sure to be honest, but we definitely need to look into it and acknowledge messages accordingly to the new version. 😅 I’ll try to have a look into it today.

Also, should dependabot automatically merge major upgrades?