BUG:Race Condition Risk in EmbeddingService Model Initialization

[g-k-s-03]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Issue Overview

The model property in EmbeddingService lazy-loads the SentenceTransformer model without any thread-safety.
This can cause multiple concurrent requests to load the model at the same time, leading to memory waste, race conditions, or crashes in a multi-threaded or async environment.

Steps to Reproduce

1. Start the backend service.
2. Trigger multiple concurrent calls to any method that accesses EmbeddingService.model (e.g., get_embedding or get_embeddings).
3. Observe that the model is loaded multiple times concurrently (check logs or GPU memory usage).
4. Optionally, run stress tests with multiple async profile summaries to see potential blocking or crashes.

Expected Behavior
The model should be loaded only once, regardless of how many concurrent requests access it.
No race conditions or duplicate memory usage should occur.

Actual Behavior
Multiple threads or async tasks can instantiate the model multiple times concurrently.
This may lead to high memory usage, GPU resource exhaustion, or task failures.

Suggested Improvements
Use a thread-safe lock when lazy-loading the model:

import threading

class EmbeddingService:
_model_lock = threading.Lock()

@property
def model(self) -> SentenceTransformer:
    if self._model is None:
        with self._model_lock:
            if self._model is None:
                self._model = SentenceTransformer(self.model_name, device=self.device)
    return self._model

This ensures only one instance of the model is created, preventing race conditions and resource duplication.

Record

• I agree to follow this project's Code of Conduct
• I want to work on this issue

[g-k-s-03]

@smokeyScraper, can you assign this issue to me? I have already startedworkingg on it

[tanii1125]

hey @g-k-s-03
I’ve opened a small PR that adds logging and observability only around EmbeddingService model initialization and reuse.

This PR does not change any concurrency, locking, or model-loading logic.
It is intended to complement the fix being worked on here by making model lifecycle behavior visible under concurrent access.

PR: #199

[g-k-s-03]

@tanii1125 Thanks for adding the logging and observability around EmbeddingService model initialization — that makes the runtime behavior under concurrent access much clearer.

I’m working on a separate PR that addresses the core issue itself by making the lazy model initialization thread-safe / async-safe. The logging PR should complement the fix well once both are in place.

[tanii1125]

Thanks! Glad the logging helps 👍
Let me know if you’d like any tweaks or additional signals logged.

[smokeyScraper]

Seems reasonable to me. I guess loading the model initially would work well, as for every new user, we index their profile. Thanks a lot @g-k-s-03, I missed this design problem xD.
Will review your PR soon and suggest any changes required.

[g-k-s-03]

Thanks @smokeyScraper!
I’m glad the approach makes sense. I’m available to address any review feedback or requested changes once you’ve had a chance to go through the PR.