fix(ci): pin ReactESP to ~3.2.0 to unbreak arduino_esp32 build#961
Closed
dirkwa wants to merge 1 commit into
Closed
fix(ci): pin ReactESP to ~3.2.0 to unbreak arduino_esp32 build#961dirkwa wants to merge 1 commit into
dirkwa wants to merge 1 commit into
Conversation
ReactESP 3.3.0 (Apr 2026) introduced two changes that the
arduino_esp32 matrix env cannot tolerate:
1. event_loop.h uses std::set::node_type, a C++17 feature, but
espressif32 @ ^6.9.0 (the Arduino-Espressif core used by the
arduino_esp32 env) defaults to C++14.
2. event_loop.h references std::vector without including <vector>,
an outright bug in 3.3.0.
The existing ^3.2.0 / ^3.1.0 constraints allow minor bumps, so every
fresh CI install pulls 3.3.0 and breaks the build (see the failed run
on PR SignalK#960). Restricting to ~3.2.0 (patches of 3.2.x only) restores a
green matrix until ReactESP ships a fixed 3.3.x.
Contributor
Author
|
I am looking now into 3.3.0, maybe we can close this and land that fix PR instead. |
Contributor
Author
|
Note: the real root-cause fix is mairas/ReactESP#40 (adds the missing |
Collaborator
|
Acknowledging the root cause, sorry about that! I've merged mairas/ReactESP#40 and released v3.3.1. Closing this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ReactESP 3.3.0 (Apr 2026) broke the
arduino_esp32CI matrix env. With the existingmairas/ReactESP @ ^3.2.0constraint, every fresh CI install now pulls 3.3.0 and fails to compile under the Arduino-Espressif toolchain. Pinning to~3.2.0restores the matrix.What 3.3.0 changed
Two upstream changes in
event_loop.h:std::set::node_type(a C++17 feature) — butespressif32 @ ^6.9.0(the platform used byarduino_esp32) defaults to C++14.std::vectorwithout#include <vector>— an outright bug in 3.3.0.The
pioarduinoenvs happen to compile fine because their newer toolchain defaults to gnu++2a and transitively pulls<vector>, but thearduino_esp32matrix entries fail like so:(see run 26077887618, the failing CI on #960 — that PR's code change is unrelated; it just happens to be the first push since 3.3.0 dropped on Apr 15.)
The change
platformio.ini:mairas/ReactESP @ ^3.2.0→~3.2.0library.json:^3.1.0→~3.2.0~3.2.0allows future3.2.xpatches but blocks3.3.xuntil upstream ships a fix.Verification
Locally built both envs against the pinned 3.2.0 on a Pi 5 (running the same
ci/run-tests.shscript CI uses):arduino_esp32—[PASSED], noevent_loop.herrors.pioarduino_esp32— compile passes (nonode_type/vectorerrors); the only local failure is an unrelatedmin_spiffs.csvlink-step issue from my multi-framework install, not present in CI.