Bumping ESPAsyncWebServer.git version to 2.4.2 to fix failing build

[booherbg]

Addresses the issue reported in #5171 ; this is based on the v0.14.4 tag which does not have a corresponding branch, so this PR would need to be cherry-picked by the upstream maintainers I think, or similar.

Summary by CodeRabbit

• Chores
  • Updated how the ESPAsyncWebServer dependency is referenced in build configuration; the resolved version remains 2.2.1. No changes to runtime behavior, API, error handling, or other dependencies.
  • No end-user visible functional changes; builds/configuration bookkeeping only.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Changed the ESPAsyncWebServer dependency specification in platformio.ini from a Git URL using an "@2.2.1" reference to the same Git URL using a "#v2.2.1" tag reference; no other files or code were modified.

Changes

Cohort / File(s)	Summary
PlatformIO config platformio.ini	Replaced ESPAsyncWebServer lib_dep Git reference form @2.2.1 with tag form #v2.2.1 (same resolved version, specification style changed).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

• Single-line spec change in one configuration file; no logic or API changes.

Possibly related issues

• WLED 0.14.4 build fails (ESPAsyncWebServer 2.2.1 does not exist) #5171 — The issue reports a build failure related to ESPAsyncWebServer dependency resolution; this PR alters the dependency spec format that the issue cites.

Suggested reviewers

• netmindz

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title claims version 2.4.2, but the actual change only updates to version 2.2.1 with a syntax change. The title is misleading about the actual version being bumped.	Update the title to accurately reflect the change, e.g., 'Update ESPAsyncWebServer dependency reference syntax to tag format' or 'Change ESPAsyncWebServer version reference from @2.2.1 to #v2.2.1'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 181552c and b2572cd.

📒 Files selected for processing (1)

• platformio.ini (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• platformio.ini

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[blazoncek]

Use #v2.2.1 tag instead of @2.2.1

[netmindz]

@ syntax is incompatible with git URLs

[blazoncek]

Never force push!

[booherbg]

@ syntax is incompatible with git URLs

I found it to be more specific than that - @ 2.4.2 actually worked where @ 2.2.1 must have stopped working at some point. My guess is that something changed relating to how the dep is registered with PlatformIO (v2.4.2 vs v2.2.1)? Either way - config is now dropped back to #2.2.1 using proper git tag syntax; the commit attached to this PR is updated

Will defer back to maintainers as to potential next steps.

Questions about the contribution process

From a process standpoint - and because I'm genuinely curious (and a huge fan of WLED in general) - hypothetically what would be the process to merge this change back into v0.14.x? Would it be a full semantic versioning patch bump to 0.14.5?

To (hypothetically) implement this, I imagine making a branch from that tag, applying this PR as a cherry-picked commit, then updating the v0.14.4 or v0.14.5 tag to point to the new branch would be one way to go.

Is there a different way that does not involve creating new branches? I ask because I don't see version related branches and thus became curious. Thank you!

[booherbg]

Never force push!

Hah good call - regrettable in hindsight sorry about that

[blazoncek]

There is no way "to merge this back". And downgrading AWS is out of the question.
If you use 0.14 from the last known commit (or tag) just update local copy. It will not change.

[booherbg]

There is no way "to merge this back". And downgrading AWS is out of the question. If you use 0.14 from the last known commit (or tag) just update local copy. It will not change.

Sounds good, thank you. It builds successfully with v2.4.2 I'm just not sure what side effects this introduces. Hopefully this PR can serve as documentation in case anyone else is interested in compiling 0.14.x locally. The "WLED Online compiler" doesn't seem to have any problems with building this version.

[netmindz]

I have created a new tag based off 0.14.4 that includes the fix

[booherbg]

Awesome, thank you.