fix: config loading set to false before being fetched

[uinstinct]

Description

Do not set config loading to false before config from hub is fetched.

In case of local config, config is already loaded in core before gui initializes (due to the constructor call).
In case of profile config, config takes time to load (due to data fetching from remote server) and profileId is not yet set.

resolves CON-3946

AI Code Review

• Team members only: AI review runs automatically when PR is opened or marked ready for review
• Team members can also trigger a review by commenting @continue-general-review or @continue-detailed-review

Checklist

• [] I've read the contributing guide
• [] The relevant docs, if any, have been updated or created
• [] The relevant tests, if any, have been updated or created

Screen recording or screenshot

before.mp4

after.mp4

Tests

[ What tests were added or updated to ensure the changes work as expected? ]

---

Summary by cubic

Fixes premature clearing of the config loading state when fetching config from the hub. The UI now stays in “Loading” until remote profile config is ready, preventing the empty-state flash and addressing CON-3946.

• Bug Fixes
  • Keep configLoading true when profileId is null and result.content.result.configLoadInterrupted; wait for configUpdate before clearing loading.
  • Update SelectedAssistantButton to prioritize the loading spinner over the “Create your first agent” message.

[RomneyDa]

@uinstinct I'm wondering if this will lead to infinite loading for local folks or folks with e.g. an error in their yaml schema. Why is the method for detecting config not yet loaded to check configLoadInterrupted?

[uinstinct]

@uinstinct I'm wondering if this will lead to infinite loading for local folks or folks with e.g. an error in their yaml schema. Why is the method for detecting config not yet loaded to check configLoadInterrupted?

Rechecked it. It does not lead to infinite loading in incorrect yaml schema

demo.mp4

The reason why configLoadInterrupted is true is because profileId is null. We do the initial fetch and load of the config in the ConfigHandler constructor call.

In case of local only config, this is immediately available (since core is initialized before gui and that ConfigLoader constructor is already called). In case of remote config, it takes a while to initialize due to the http calls (and config/getSerializedProfileInfo is already called in gui).

[RomneyDa]

@uinstinct in your video, it doesn't lead to infinite loading because a profile Id was selected. I understand that profileId === null and configLoadingInterrupted = true can be used to detect loading conditions with the current profileId setup, but the condition feels fragile since configLoadingInterrupted = true in other cases as well, e.g.
, and there is no first principles reason that profileId would not be null in other cases as well. So you would expect situations in which profileId is null and config load is interrupted and we would not set configLoading = true.

Can we come up with a more robust way to detect this?