Disabled SDC components are re-enabled after cache rebuild

Hello @heyyo

I attempted to replicate the issue, but as per the description everything seems to be working as expected.

Here are the steps I followed:
1. I manually disabled one of the components via /admin/appearance/component.
2. The component correctly appeared under the Disabled Components tab at /admin/appearance/component/status.
3. I cleared the cache both via Drush and through the UI at /admin/config/development/performance. The component remained disabled as expected.

However, I did notice an inconsistency:
When I disabled the component, it was correctly listed under the Disabled Components tab, but it was not removed from the Enabled Components tab. As a result, the component appeared in both tabs simultaneously, which could be misleading.

This seems to indicate a UI or rendering issue where the list of enabled components is not being updated properly after a change.

Please can you help me with more details on it.

Thanks.

I'm able to reproduce the same behaviour as @jatingupta40 - disabling an SDC component shows that component in both lists. Interestingly under "disabled components" the status for the component shows as "Incompatible" but the reason shows as "Manually disabled" I think that the status here maybe at least part of the problem and it should be marked as "Disabled" and not "Incompatible".

@heyyo can you re-test and confirm if this is the same behaviour you're seeing if not provide some more steps to reproduce.

Just yesterday I happen to have worked on this code in #3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row — the place to update is src/Plugin/ExperienceBuilder/ComponentSource/SingleDirectoryComponent.php.

Great find!

We're definitely lacking test coverage for this. I think a new ComponentSourceTestBase::testUpdateDiscovery() would probably make sense?

Thanks @heyyo for the descriptive steps.
I have checked the scenario as per #5, and now i can reproduce the issue.

I've found the code that looks to have been causing this, it was recently changed. I've created an MR to run all the tests and will need further testing. It may need more logic rather than just removing the enable function and some tests around this.

All the tests look good. Assigning to myself to look at adding a test for this next.

This elegantly fixes a confusing behavior 👍

Minor lingering concern that needs a minor follow-up:

1. I've got a module foo installed that provides a hello SDC
2. if I uninstall foo, then the sdc.hello Component config entity will be disabled by \Drupal\experience_builder\Entity\Component::onDependencyRemoval()
3. if I now reinstall foo because I realize my mistake, then sdc.hello will start working again … but it will not appear in the list of available components in the UI anymore, because it remains disabled

Follow-up created: #3528075: `Component::onDependencyRemoval()` should store the reason for disabling that Component.