client respawn loop

[Tweekazoid]

==============================================================================
BUG REPORT - BlenderKit add-on: client respawn loop pins CPU at 100% and
hangs Blender when the local client cannot reach the server

Date: 2026-07-03
Reporter: vinayak26sept@gmail.com
Blender: 4.5.11 LTS and 5.1.2 (Microsoft Store builds, Windows)
Add-on version: BlenderKit add-on v3.19.2.260411 (on 4.5)
Client versions seen: v1.8.3, v1.9.2
Platform: Windows 11 Home (see system_info.txt)

---

SUMMARY (one line)

When the BlenderKit background client cannot bind its port or answer the
add-on's HTTP poll in time, the add-on kills and restarts the client in a
tight loop (10+ restarts per minute). Each restart spikes a CPU core; the
cumulative effect drives total CPU to 100-210%, making Blender lag and
"hang" during ordinary editing (e.g. entering Edit Mode). Disabling the
add-on immediately stops the spikes.

---

IMPACT

• Blender becomes progressively laggy the longer a session runs.
• Simple operations (move object, enter Edit Mode) stutter and appear to hang.
• A fresh file is fine; degradation builds as the failed-request/respawn
  cycle accumulates.
• Confirmed NOT caused by scene content: an instrumented depsgraph timer
  (attached logic) recorded ZERO slow scene updates during the spikes. The
  CPU load is entirely from the client respawn loop, not from mesh evaluation.

---

ROOT CAUSE (three distinct but related defects observed)

DEFECT 1 - Respawn loop on client poll timeout
The add-on polls the client at http://127.0.0.1: with a very short
read timeout (0.25 s). On any timeout it logs:
"First request for BKClient reports failed unexpectedly:
HTTPConnectionPool(host='127.0.0.1', port=62485):
Read timed out. (read timeout=0.25)"
...and then immediately restarts the client:
"Blendkit-Client v1.9.2 starting on http://127.0.0.1:62485"
"Blendkit-Client is running on port 62485!"
This repeats every few seconds for the entire session. A 0.25 s timeout is
far too aggressive; a momentarily busy client is treated as dead and killed.

DEFECT 2 - Port bind failure from stale/orphaned clients (WSAEADDRINUSE)
Old client processes are not always cleaned up. New clients then fail:
"Failed to start Client server on 127.0.0.1:62485:
listen tcp 127.0.0.1:62485: bind: Only one usage of each socket
address ... is normally permitted. errno:10048 (WSAEADDRINUSE)"
Result: the add-on shows the red banner
"Client failed to start, add-on will not work"
and the panel is dead until the stale processes are killed manually.
(See attachments/client_portbind_failure_4.5.log)

DEFECT 3 - Thumbnails never load if the temp folder is removed at runtime
If the client's temp thumbnail folder is deleted while Blender runs
(Windows Storage Sense / temp cleanup does this), the client does not
recreate it. Every thumbnail write then fails:
"thumbnail_download FAILED: open
...\Temp\bktemp_vinay\material_search\thumbnail_*.png.webp:
The system cannot find the path specified."
The search grid stays on "Loading..." indefinitely.
(See attachments/thumbnail_download_failures_excerpt.log)

Additionally, ~68 cached asset .blend files in blenderkit_data were
truncated/corrupted and fail to read on every scene load:
"Failed to read blend file ...: Missing DNA block"
"Unrecognized file format ..."
suggesting incomplete-download handling does not validate or re-fetch.

---

EVIDENCE (measured, external to Blender)

A lightweight external watchdog sampled blender.exe CPU and the client
processes every 3 seconds. Over the session it recorded:
40 CPU-SPIKE events (blender at 80-210% CPU)
10 CLIENT-SPAWNED events (new client PID appearing, then dying seconds later)
The spikes and the respawns are time-correlated. The MOMENT the add-on was
disabled, both stopped completely and stayed silent (verified 4+ minutes).
Full log: attachments/external_watchdog_cpu_and_respawn_evidence.log

---

STEPS TO REPRODUCE

1. Windows machine, BlenderKit add-on enabled, panel open.
2. Put the client in a state where it cannot answer within 0.25 s
   (busy client, slow/blocked network to the server, or a stale client
   still holding the port).
3. Work in the viewport for several minutes.
   -> Observe repeated "Read timed out" + "Client ... starting" cycles in
   the console and rising CPU with editing stutter.

---

SUGGESTED FIXES (for the developers)

1. Increase the client poll read timeout well above 0.25 s (e.g. 2-5 s), and
   add exponential backoff before restarting the client.
2. Add a restart rate limit / circuit breaker: after N failed starts, stop
   respawning, surface one clear error, and idle instead of looping.
3. On startup, detect and terminate orphaned client PIDs, or pick a free
   port instead of failing on WSAEADDRINUSE.
4. Have the client re-create its temp thumbnail directory if missing before
   writing, rather than erroring per-file.
5. Validate cached asset .blend files after download; re-fetch or discard
   files with "Missing DNA block" instead of re-reading them every session.

---

FILES IN THIS REPORT

BUG_REPORT.txt - this file
system_info.txt - hardware / OS
attachments/client_portbind_failure_4.5.log - Defect 2 raw log
attachments/thumbnail_download_failures_excerpt.log- Defect 3 raw log
attachments/external_watchdog_cpu_and_respawn_evidence.log - Defect 1 evidence

[Tweekazoid]

#2204