IEP-1746 Fix IllegalStateException in ActiveLaunchConfigurationProvider when JobManager is suspended#1432
Merged
Conversation
📝 WalkthroughWalkthroughRemoved Changes
Sequence Diagram(s)sequenceDiagram
participant Caller as IDFBuildConfiguration / IdfCommandExecutor
participant Service as IDFCorePlugin (OSGi service registry)
participant Manager as ILaunchBarManager
participant Config as ILaunchConfiguration
Caller->>Service: getService(ILaunchBarManager.class)
alt service available
Service-->>Caller: ILaunchBarManager
Caller->>Manager: getActiveLaunchConfiguration()
alt configuration present
Manager-->>Caller: ILaunchConfiguration
Caller->>Config: getAttribute(name, default)
Config-->>Caller: property value
else no configuration
Manager-->>Caller: null
Caller-->>Caller: log warning / fallback to super.getProperty()
Caller-->>Caller: return fallback value
end
else service unavailable
Service-->>Caller: null
Caller-->>Caller: log warning / fallback to super.getProperty()
Caller-->>Caller: return fallback value
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java`:
- Around line 200-203: The warning in IDFBuildConfiguration.getProperty logs
every time configuration == null which is noisy; change it to a lower log level
or log it only once. Update the branch that currently calls Logger.log("Warning:
Launch Bar not ready...") so it either uses a debug/trace/info call instead of
warning, or guard it with a one-time flag (e.g., a private static
boolean/AtomicBoolean) so the message is emitted only once, then continue to
return super.getProperty(name) as before; reference:
IDFBuildConfiguration.getProperty, the configuration variable and the return
super.getProperty(name) line.
- Around line 200-213: The early return in IDFBuildConfiguration.getProperty
when configuration == null skips the intended fallback to persisted settings;
change the logic so that when configuration is null you do not return
super.getProperty(name) immediately but instead let the method continue to
compute property by first checking the (absent) launch configuration and then
falling back to getSettings().get(name, StringUtil.EMPTY) (or finally
super.getProperty(name) only if both configuration and getSettings() produce
empty), i.e., remove the immediate return and ensure getSettings() is consulted
before delegating to super.getProperty; update references in
IDFBuildConfiguration.getProperty and preserve the existing resolution order
(launch config → getSettings() → super.getProperty).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5d2a888b-7256-4a39-afb2-18a1542236fc
📒 Files selected for processing (4)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MFbundles/com.espressif.idf.core/src/com/espressif/idf/core/build/ActiveLaunchConfigurationProvider.javabundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.javatests/com.espressif.idf.core.test/src/com/espressif/idf/core/test/ActiveLaunchConfigurationTest.java
💤 Files with no reviewable changes (2)
- bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/ActiveLaunchConfigurationProvider.java
- tests/com.espressif.idf.core.test/src/com/espressif/idf/core/test/ActiveLaunchConfigurationTest.java
Comment on lines
+200
to
+203
| if (configuration == null) | ||
| { | ||
| Logger.log("Warning: Launch Bar not ready. Falling back to default properties for " + name); //$NON-NLS-1$ | ||
| return super.getProperty(name); |
There was a problem hiding this comment.
Avoid warning-level logging on this hot path.
getProperty() is called a lot, and configuration == null is a normal transient state during Launch Bar startup. Emitting a warning here can easily replace the old startup noise with a new one. Please downgrade this or log it once.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java`
around lines 200 - 203, The warning in IDFBuildConfiguration.getProperty logs
every time configuration == null which is noisy; change it to a lower log level
or log it only once. Update the branch that currently calls Logger.log("Warning:
Launch Bar not ready...") so it either uses a debug/trace/info call instead of
warning, or guard it with a one-time flag (e.g., a private static
boolean/AtomicBoolean) so the message is emitted only once, then continue to
return super.getProperty(name) as before; reference:
IDFBuildConfiguration.getProperty, the configuration variable and the return
super.getProperty(name) line.
Comment on lines
+200
to
213
| if (configuration == null) | ||
| { | ||
| Logger.log("Warning: Launch Bar not ready. Falling back to default properties for " + name); //$NON-NLS-1$ | ||
| return super.getProperty(name); | ||
| } | ||
|
|
||
| if (configuration.getType().getIdentifier().equals(IDFLaunchConstants.DEBUG_LAUNCH_CONFIG_TYPE)) | ||
| { | ||
| configuration = new LaunchUtil(DebugPlugin.getDefault().getLaunchManager()) | ||
| .getBoundConfiguration(configuration); | ||
| } | ||
| String property = configuration == null ? StringUtil.EMPTY | ||
| : configuration.getAttribute(name, StringUtil.EMPTY); | ||
|
|
||
| String property = configuration.getAttribute(name, StringUtil.EMPTY); | ||
| property = property.isBlank() ? getSettings().get(name, StringUtil.EMPTY) : property; |
There was a problem hiding this comment.
Preserve the existing settings fallback when no active launch configuration exists.
This early return changes the resolution order from “launch config, then getSettings()” to super.getProperty(name) whenever Launch Bar is not ready. That means persisted IDF build properties can disappear during startup even though the fallback logic is still present a few lines below.
Suggested fix
if (configuration == null)
{
- Logger.log("Warning: Launch Bar not ready. Falling back to default properties for " + name); //$NON-NLS-1$
- return super.getProperty(name);
+ Logger.log("Warning: Launch Bar not ready. Falling back to persisted properties for " + name); //$NON-NLS-1$
+ String property = getSettings().get(name, StringUtil.EMPTY);
+ return property.isBlank() ? super.getProperty(name) : property;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java`
around lines 200 - 213, The early return in IDFBuildConfiguration.getProperty
when configuration == null skips the intended fallback to persisted settings;
change the logic so that when configuration is null you do not return
super.getProperty(name) immediately but instead let the method continue to
compute property by first checking the (absent) launch configuration and then
falling back to getSettings().get(name, StringUtil.EMPTY) (or finally
super.getProperty(name) only if both configuration and getSettings() produce
empty), i.e., remove the immediate return and ensure getSettings() is consulted
before delegating to super.getProperty; update references in
IDFBuildConfiguration.getProperty and preserve the existing resolution order
(launch config → getSettings() → super.getProperty).
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java (1)
200-215:⚠️ Potential issue | 🟠 MajorKeep the original fallback order here.
Lines 203 and 215 now skip the persisted
getSettings()/default fallback chain in transient Launch Bar startup states, so saved IDF build properties can disappear until the service finishes initializing.configuration == nullis also expected on this path, so warning-level logging on every call will be noisy. Please preservelaunch config → getSettings() → superand lower or de-duplicate the log.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java` around lines 200 - 215, Preserve the original fallback order in IDFBuildConfiguration.getProperty: remove the early return when configuration == null and stop logging a warning on every call; instead, only log at a lower level or once. Keep the DEBUG_LAUNCH_CONFIG_TYPE binding via LaunchUtil(DebugPlugin.getDefault().getLaunchManager()).getBoundConfiguration(configuration) when configuration is non-null, then read property = (configuration != null) ? configuration.getAttribute(name, StringUtil.EMPTY) : StringUtil.EMPTY; if property is blank, fall back to getSettings().get(name, StringUtil.EMPTY); if still blank, return super.getProperty(name). Replace the noisy Logger.log warning with a debug/info-level log or de-duplicated log that only triggers once when the launch bar is uninitialized.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java`:
- Around line 192-198: IdfCommandExecutor still imports and instantiates the
removed ActiveLaunchConfigurationProvider; locate the static field and import in
IdfCommandExecutor and either remove them if unused or replace their usage with
the new ILaunchBarManager pattern: get ILaunchBarManager via
IDFCorePlugin.getService(ILaunchBarManager.class) and call
getActiveLaunchConfiguration() (same approach as in IDFBuildConfiguration) to
obtain the active ILaunchConfiguration, updating any callers that referenced
ActiveLaunchConfigurationProvider accordingly; ensure you remove the obsolete
import and static field declaration if you adopt the new manager.
---
Duplicate comments:
In
`@bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.java`:
- Around line 200-215: Preserve the original fallback order in
IDFBuildConfiguration.getProperty: remove the early return when configuration ==
null and stop logging a warning on every call; instead, only log at a lower
level or once. Keep the DEBUG_LAUNCH_CONFIG_TYPE binding via
LaunchUtil(DebugPlugin.getDefault().getLaunchManager()).getBoundConfiguration(configuration)
when configuration is non-null, then read property = (configuration != null) ?
configuration.getAttribute(name, StringUtil.EMPTY) : StringUtil.EMPTY; if
property is blank, fall back to getSettings().get(name, StringUtil.EMPTY); if
still blank, return super.getProperty(name). Replace the noisy Logger.log
warning with a debug/info-level log or de-duplicated log that only triggers once
when the launch bar is uninitialized.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 54181e16-367b-4391-a846-464c84dee898
📒 Files selected for processing (4)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MFbundles/com.espressif.idf.core/src/com/espressif/idf/core/build/ActiveLaunchConfigurationProvider.javabundles/com.espressif.idf.core/src/com/espressif/idf/core/build/IDFBuildConfiguration.javatests/com.espressif.idf.core.test/src/com/espressif/idf/core/test/ActiveLaunchConfigurationTest.java
💤 Files with no reviewable changes (2)
- tests/com.espressif.idf.core.test/src/com/espressif/idf/core/test/ActiveLaunchConfigurationTest.java
- bundles/com.espressif.idf.core/src/com/espressif/idf/core/build/ActiveLaunchConfigurationProvider.java
✅ Files skipped from review due to trivial changes (1)
- bundles/com.espressif.idf.core/META-INF/MANIFEST.MF
There was a problem hiding this comment.
🧹 Nitpick comments (1)
bundles/com.espressif.idf.core/src/com/espressif/idf/core/util/IdfCommandExecutor.java (1)
102-108: Consider logging the missing Launch Bar service path.When
IDFCorePlugin.getService(ILaunchBarManager.class)returnsnull,getProperty()now falls through toStringUtil.EMPTY, which is indistinguishable from “attribute not set.” A small debug/warn breadcrumb here would keep the non-blocking fix while making startup timing issues much easier to diagnose.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@bundles/com.espressif.idf.core/src/com/espressif/idf/core/util/IdfCommandExecutor.java` around lines 102 - 108, The code path where IDFCorePlugin.getService(ILaunchBarManager.class) returns null should emit a non-blocking diagnostic log so callers of getProperty() can distinguish "service unavailable" from "attribute unset"; update IdfCommandExecutor to detect launchBarManager == null and call the plugin logger (or IDFCorePlugin's logging helper) with a debug/warn message indicating the Launch Bar service was unavailable at startup before continuing to the existing StringUtil.EMPTY fallback, referencing the getActiveLaunchConfiguration() call so the log can be correlated to this code path.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@bundles/com.espressif.idf.core/src/com/espressif/idf/core/util/IdfCommandExecutor.java`:
- Around line 102-108: The code path where
IDFCorePlugin.getService(ILaunchBarManager.class) returns null should emit a
non-blocking diagnostic log so callers of getProperty() can distinguish "service
unavailable" from "attribute unset"; update IdfCommandExecutor to detect
launchBarManager == null and call the plugin logger (or IDFCorePlugin's logging
helper) with a debug/warn message indicating the Launch Bar service was
unavailable at startup before continuing to the existing StringUtil.EMPTY
fallback, referencing the getActiveLaunchConfiguration() call so the log can be
correlated to this code path.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4c6f1a97-4da7-4d1e-960e-ec4e89fdc521
📒 Files selected for processing (1)
bundles/com.espressif.idf.core/src/com/espressif/idf/core/util/IdfCommandExecutor.java
AndriiFilippov
approved these changes
Apr 21, 2026
Collaborator
AndriiFilippov
left a comment
AndriiFilippov
left a comment
There was a problem hiding this comment.
@sigmaaa hi !
Tested under:
OS: Windows 11 / Linux Ubuntu
ESP-IDF: v5.5
do see warning Warning: Launch Bar not ready. Falling back to default properties for cdt.toolChain.type instead of error ✔️
LGTM 👍
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
3 participants
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.
Description
Removed ActiveLaunchConfigurationProvider to avoid IllegalStateException and replaced it with a simpler approach of retrieving the active launch configuration from the Launch Bar service.
Fixes # (IEP-1746)
Type of change
Please delete options that are not relevant.
How has this been tested?
Restart IDE multiple times and see logs if there is no such message "!MESSAGE Join was called on job "Launch Bar Initialization" while JobManager is suspended, this will not work as expected!"
Test Configuration:
Dependent components impacted by this PR:
Checklist
Summary by CodeRabbit
Refactor
Chores