fix: harden DevWorkspace watch lifecycle and IDE status check (CRW-12992)

[adietish]

fixes https://redhat.atlassian.net/browse/CRW-12992

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: acabc3d1-9abb-4c04-8dd2-ffaa45b7cb6f

---

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

[codecov-commenter]

Codecov Report

❌ Patch coverage is 51.53374% with 79 lines in your changes missing coverage. Please review.
✅ Project coverage is 39.80%. Comparing base (71098f6) to head (0a3d968).
⚠️ Report is 436 commits behind head on main.

Files with missing lines	Patch %	Lines
.../gateway/view/steps/DevSpacesWorkspacesStepView.kt	0.00%	52 Missing ⚠️
...ateway/view/steps/workspaces/DevWorkspacesTable.kt	0.00%	14 Missing ⚠️
...ateway/devworkspace/WorkspaceEditorInfoProvider.kt	85.48%	3 Missing and 6 partials ⚠️
...s/gateway/devworkspace/DevWorkspaceWatchManager.kt	85.18%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            main     #377       +/-   ##
==========================================
+ Coverage   0.00%   39.80%   +39.80%     
==========================================
  Files          4      123      +119     
  Lines         26     5363     +5337     
  Branches       0     1032     +1032     
==========================================
+ Hits           0     2135     +2135     
- Misses        26     2943     +2917     
- Partials       0      285      +285     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vrubezhny]

I don't spot any problems with this PR. The only effect of non-JB Editor-based WSs not being watched: the status icon for such WSs doesn't get updated automatically (users always need to click Refresh to see actual states).
As result, Stat and Stop buttons may work unpredictably as their handlers don't check the current DevWorkspace spec.started value and once clicked patch it with no any precautions . This is probably a subject to be fixed (we either need to refresh the selected DevWorkspace object before executing Start/Stop or warn user and ask to Refresh before clicking these.)

Probably the same could happen to the "Unknown"/"Not-detected"-like WSs (we've added the possibility to be started to). Also in this case the Connect button's handler may try connecting to a WS that isn't really running while it has to.

For the WSs detected clearly as JBs Editor based ones everything works perfectly. During my ~2hrs testing session, with the total started thread count (shown by jconsole <PID>) >1000, the maximum running thread number has never exceeded 132, in "idle" state the number of running threads was heading to ~50, while rising to 75-85 threads when performing some actions, like start/stop WS, refreshing, connecting (including up to the WS project appearance in thinClient, stopping it together with the WS or letting the WS to continue running). The same patterns were repeating during the session so no anything like "constant growth of the running threads number" has been found.

[vrubezhny]

Not sure if this is anything related to the PR, but I spotted the WS status icons flickering. No actions taken, no WSs changed from outside (I'm not 100% sure about this, but at least I haven't performed any changed in WebDashboard while recording it), no thread counters changing, so it's the same WS-monitor's thread issue:

output-looped-5-times.mp4

This screencast video is looped 5 times, but the effect gets repeating once in a few minutes with no any action actually taken while, I suppose, any WS that failed shouldn't change its state until explicitly altered.

PS: Buttons are actually flickering too - the effect is clearly seen to me when a Running WS is selected:

output-flickering-buttons-looped-5-times.mp4

[adietish]

@vrubezhny the "flickering" that you see is not related to this PR. If you think that this PR is otherwise OK, please +1 it.

This "flickering" is related to the tabular listing of the workspaces that shows editors for workspaces. The workspace editors are fetched in a background thread #359 and the editor column updated. Maybe there's a glitch where update would not have to be updated. I cannot clearly see it in the videos. If you think that this is a bug and should be enhanced, we should file a new bug.

[adietish]

@vrubezhny I guess that we should either disable start/stop for non-jetbrains workspaces or watch these for status updates, too. What you report is definitely inconsistent behaviour.

[adietish]

@vrubezhny I am now back to watching all workspaces. Only watching jetbrains workspaces may reduce the number of threads but introduces inconsistencies. Not worth it.

This PR now has the following fixes:

• DevWorkspaceWatch.stop() now closes the current watch, which unblocks the stuck IO thread immediately instead of waiting for the OkHttp read timeout — previously stopped watches leaked their blocking threads.
• DevWorkspaceWatchManager.start() now stops all watches first, so repeated refreshes no longer accumulate duplicate watchers per namespace — the main growth driver of pool exhaustion.

Please re-review, thanks!

[adietish]

@vrubezhny, @azatsarynnyy please review

[adietish]

@vrubezhny: I filed the flickering issue to https://redhat.atlassian.net/browse/CRW-13522

[vrubezhny]

Looks good to me, Thanks!