This is a comment left during a code review.
Path: backend/backend/worker_celery.py
Line: 61-63

Comment:
**Unsynchronised singleton initialisation — race condition under concurrent requests**

`get_worker_celery_app()` uses the classic double-check-without-lock pattern:

```python
if _worker_app is not None:
    return _worker_app
```

Under gunicorn with threaded workers (or any multi-threaded Django deployment), two threads can simultaneously see `_worker_app is None` and both proceed to create a new `_WorkerDispatchCelery` instance. The second assignment overwrites the first (last-writer-wins), so each thread may end up holding a reference to a *different* object than what ends up in the module global. This is benign in practice because both instances are configured identically, but it is wasteful and could cause subtle issues if Celery connection pools are per-instance.

The idiomatic Python fix is to use a module-level lock:

```python
import threading
_worker_app: Celery | None = None
_worker_app_lock = threading.Lock()

def get_worker_celery_app() -> Celery:
    global _worker_app
    if _worker_app is not None:
        return _worker_app
    with _worker_app_lock:
        if _worker_app is None:   # re-check inside lock
            ...
            _worker_app = app
    return _worker_app
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: workers/executor/executors/answer_prompt.py
Line: 44-76

Comment:
**DNS rebinding (TOCTOU) bypasses SSRF protection**

`_is_safe_public_url` resolves the webhook hostname via DNS at *validation time*, but the actual HTTP request to the webhook (via `postprocess_data`) happens *afterwards*. An attacker who controls a DNS server can perform a DNS rebinding attack:

1. During validation: `attacker.com` → `1.2.3.4` (a public IP) — validation passes.
2. Attacker flips DNS TTL to 0 and rebinds `attacker.com` → `169.254.169.254` (AWS metadata), `10.0.0.1` (internal service), etc.
3. During the actual HTTP request: the OS re-resolves `attacker.com` and connects to the internal address.

The current `is_private` / `is_loopback` / etc. checks are bypassed entirely because they only guard the validation-time resolution. This is a real risk in a multi-tenant environment where arbitrary webhook URLs can be registered.

The standard mitigation is to make the HTTP request through a socket-level wrapper that re-validates the resolved IP *at connection time* — for example by overriding the socket's `connect()` to check the destination address immediately before the connection is established, or by using a library such as [urllib3-pyOpenSSL](https://github.com/urllib3/urllib3) with a custom `ProxyManager`, or setting a fixed DNS-resolved IP on the `requests` session host header.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: backend/prompt_studio/prompt_studio_core_v2/prompt_studio_helper.py
Line: 392-395

Comment:
**`set_document_indexing` not rolled back on broker failure**

`DocumentIndexingService.set_document_indexing(...)` is called at the end of `build_index_payload` (before `dispatch_with_callback` is called in the view). If `dispatch_with_callback` subsequently raises — for example, because the broker is unavailable, the Celery app is not configured, or any other exception — the document is permanently left in the "indexing in progress" state. The `ide_index_error` errback is never invoked because no task was dispatched, so there is no mechanism to clear the stuck flag.

The view code does not wrap `dispatch_with_callback` in a try/except that would call `DocumentIndexingService.remove_document_indexing(...)` on failure. The result is that the user sees an infinite "indexing in progress" indicator and cannot re-index the document without manual DB intervention.

To fix this, either:
1. Move `set_document_indexing` to after successful dispatch (wrap the dispatch, set the flag only on success), or
2. Add a `try/except` around `dispatch_with_callback` in the view that calls `remove_document_indexing` on error.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: backend/prompt_studio/prompt_studio_core_v2/prompt_studio_helper.py
Line: 855-865

Comment:
**Missing `profile_manager_id` in `single_pass_extraction` `cb_kwargs`**

`build_single_pass_payload` does not include `profile_manager_id` in its `cb_kwargs` (lines 855–865). When `ide_prompt_complete` processes this callback it reads:

```python
profile_manager_id = cb.get("profile_manager_id")  # always None for single-pass
```

and passes `profile_manager_id=None` to `OutputManagerHelper.handle_prompt_output_update`. Depending on how that helper uses the field, single-pass outputs may not be correctly associated with the profile manager, producing a different storage behavior than the `fetch_response` path (which always passes the explicit `profile_manager_id`).

More concretely, when `ide_prompt_error` fires for a single-pass failure, the emitted error event also lacks `profile_manager_id`. The frontend's `handleFailed` falls through to the broad `clearPromptStatusById(promptId)` fallback, which clears ALL doc/profile status combinations for those prompts — not just the one that was actually running. This means an error in one single-pass run would cancel the loading spinners for unrelated concurrent runs.

Consider adding the default profile's `profile_id` to `cb_kwargs`:

```python
cb_kwargs = {
    ...
    "profile_manager_id": str(default_profile.profile_id),
    ...
}
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: frontend/src/hooks/usePromptStudioSocket.js
Line: 131-149

Comment:
**Socket result event not scoped to the current tool — multi-tab state corruption**

`prompt_studio_result` events are emitted to the `log_events_id` Socket.IO room, which is per-user-session, not per-tool or per-tab. If a user has two Prompt Studio tools open simultaneously in separate tabs (both sharing the same Socket.IO connection and `log_events_id`), a result from Tool A's execution will be received and processed by Tab B's `usePromptStudioSocket` listener as well.

In `handleCompleted("fetch_response", result)`:
```js
updatePromptOutputState(data, false);  // writes Tool A's outputs into Tab B's store
clearResultStatuses(data);             // tries to clear statuses using Tool A's prompt IDs
```

`updatePromptOutputState` in Tab B would overwrite prompt output state with data belonging to Tool A's prompts. This can cause phantom outputs to appear under the wrong tool and leave Tab B in an inconsistent state.

The socket event payload (`_emit_result` in `tasks.py`) does not include a `tool_id` field, so the frontend has no way to discard irrelevant events. Consider adding `tool_id` (or `custom_tool_id`) to the emitted payload and filtering it in `onResult`:

```js
const onResult = useCallback((payload) => {
  const msg = payload?.data || payload;
  if (msg.tool_id && msg.tool_id !== details?.tool_id) return; // ignore events for other tools
  ...
}, [..., details?.tool_id]);
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: frontend/src/hooks/usePromptStudioSocket.js
Line: 28-44

Comment:
**`clearResultStatuses` spinner-clearing may permanently fail**

`clearResultStatuses` derives the status key from `item.profile_manager` on the result data items. The status was originally stored using a `profileId` taken directly from the queue item string — a raw UUID string. For `clearResultStatuses` to match and call `removePromptStatus`, `item.profile_manager` in the result data must be the exact same UUID string.

If `OutputManagerHelper.handle_prompt_output_update` returns serialized objects where `profile_manager` is an integer PK, a nested object, or `null`, the condition `if (promptId && docId && profileId)` will be false, `removePromptStatus` will never be called, and the loading spinner for the prompt will remain active forever. The user would be unable to re-run the prompt without a page refresh.

The old polling path avoided this by explicitly removing the status with the IDs already available in the callback closure. The new socket path has no such explicit fallback.

Consider including `prompt_ids`, `document_id`, and `profile_manager_id` in the socket event payload (they are already present in `cb_kwargs`) so the frontend can always do a direct cleanup regardless of the result data format, rather than relying on parsing the ORM-serialized result items.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: frontend/src/hooks/usePromptRun.js
Line: 56-70

Comment:
**5-minute timeout can falsely cancel a later re-run of the same prompt**

The `setTimeout` closure captures `promptId`, `docId`, and `profileId` from run N. When it fires 5 minutes later it reads the *current* store state and checks whether `current?.[promptId]?.[statusKey] === PROMPT_RUN_API_STATUSES.RUNNING`. If the user triggered another run of the same `(promptId, docId, profileId)` combination (run N+1) within that 5-minute window, the timer from run N will see run N+1's `RUNNING` state, clear it, and display a spurious "timed out" warning — even though run N+1 may still be processing and will later receive a valid socket event. The result is a permanently stuck spinner for run N+1 (status cleared by the stale timer) while the socket result arrives and tries to call `clearResultStatuses` on an already-removed entry.

Mitigation: tag each dispatch with a unique `runId` and include it in the status store key, so the timeout only clears the *specific* run it corresponds to:

```js
const runNonce = generateUUID();
addPromptStatus(promptId, statusKey, PROMPT_RUN_API_STATUSES.RUNNING, runNonce);

setTimeout(() => {
  const current = usePromptRunStatusStore.getState().promptRunStatus;
  if (current?.[promptId]?.[statusKey]?.nonce === runNonce) {
    removePromptStatus(promptId, statusKey);
    setAlertDetails({ type: "warning", content: "Prompt execution timed out. Please try again." });
  }
}, SOCKET_TIMEOUT_MS);
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: backend/prompt_studio/prompt_studio_core_v2/prompt_studio_helper.py
Line: 297-302

Comment:
**`default_profile` dereferenced before null guard in `build_index_payload`**

`build_index_payload` calls `ProfileManager.get_default_llm_profile(tool)`, then immediately passes the result to `validate_adapter_status` and `validate_profile_manager_owner_access` without any null check. If no default LLM profile is configured for the tool, `get_default_llm_profile` returns `None` and both validators will raise `AttributeError` deep inside the helper, surfacing as an opaque 500 error instead of the intended `DefaultProfileError`.

The same defensiveness present in `build_single_pass_payload` (`if not default_profile: raise DefaultProfileError()`) should be applied here:

```python
default_profile = ProfileManager.get_default_llm_profile(tool)
if not default_profile:
    raise DefaultProfileError()

PromptStudioHelper.validate_adapter_status(default_profile)
PromptStudioHelper.validate_profile_manager_owner_access(default_profile)
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: backend/prompt_studio/prompt_studio_core_v2/views.py
Line: 430-443

Comment:
**HubSpot first-run analytics event silently dropped in async path**

The old sync `fetch_response` path tracked `output_count_before` and called `notify_hubspot_event(user, "PROMPT_RUN", is_first_for_org=..., ...)` to fire a business analytics event on the first prompt run for an organisation. The new async path removes both the count query and the notification call entirely with no comment or TODO.

If this is intentional (e.g., to be re-added once the async path is stable), a comment noting this would prevent it from being permanently lost. If it is unintentional, first-run HubSpot events will silently stop firing for any organisation that has `async_prompt_execution` enabled, skewing adoption metrics.

How can I resolve this? If you propose a fix, please make it concise.