src/renderer/components/Experiment/Tasks/JobProgress.tsx (1)

111-141: Well-implemented live status display with clear state handling.

The function correctly handles the three live status states with appropriate colors (neutral for started/finished, danger for crashed). The null check ensures graceful fallback when live_status is unavailable.

Consider adding live_status to the JobData interface for better type safety:

 interface JobData {
   start_time?: string;
   end_time?: string;
   completion_status?: string;
   completion_details?: string;
+  live_status?: 'started' | 'crashed' | 'finished';
   [key: string]: any;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/JobProgress.tsx` around lines 111 -
141, Add the missing live_status property to the JobData type so TypeScript can
type-check usages like job.job_data.live_status (used in
renderLiveStatusSubtitle); update the JobData interface/typedef to include
live_status with an appropriate union type (e.g., 'started' | 'crashed' |
'finished' | undefined/null) and adjust any places that construct or parse
job.job_data to satisfy the new property type.

lab-sdk/src/lab/remote_trap.py (1)

30-43: Consider using asyncio.get_running_loop() for Python 3.10+ compatibility.

asyncio.get_event_loop() emits a DeprecationWarning when called without a running event loop in Python 3.10+. The current code works but may generate warnings.

Proposed modernization

     try:
         asyncio.run(_set_live_status_async(job_id, status))
     except RuntimeError:
-        # Fallback in case an event loop already exists.
         try:
-            loop = asyncio.get_event_loop()
-            if loop.is_running():
-                # In the unlikely case we're already in an event loop, schedule the task
-                # but don't wait on it (best-effort update).
+            loop = asyncio.get_running_loop()
+            # Already in an event loop, schedule the task but don't wait (best-effort).
-                loop.create_task(_set_live_status_async(job_id, status))
-            else:
-                loop.run_until_complete(_set_live_status_async(job_id, status))
+            loop.create_task(_set_live_status_async(job_id, status))
         except Exception:
             return

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@lab-sdk/src/lab/remote_trap.py` around lines 30 - 43, The current fallback
uses asyncio.get_event_loop() which can emit DeprecationWarnings on Python
3.10+; update the fallback in the block that calls
asyncio.run(_set_live_status_async(job_id, status)) to prefer
asyncio.get_running_loop() and only call asyncio.get_event_loop() as a last
resort: attempt to retrieve the running loop with asyncio.get_running_loop(), if
it exists and is running schedule the task with
loop.create_task(_set_live_status_async(job_id, status)), otherwise use
loop.run_until_complete(_set_live_status_async(job_id, status)) (or if no
running loop is available, create one safely); keep the outer try/except
behavior and ensure exceptions still result in the existing silent return.

api/transformerlab/routers/compute_provider.py (1)

1673-1702: Crash detection logic is correct, but consider extracting to a service.

The live_status crash handling correctly marks the job as FAILED with proper end_time recording. However, this adds business logic directly in the router.

Per coding guidelines, business logic should be placed in api/transformerlab/services/ using the Service pattern. The existing code in this file follows a similar inline pattern, so this is consistent, but future refactoring could extract job status update logic to job_service.

Potential service extraction

Consider adding a helper in job_service.py:

async def mark_job_as_crashed(job_id: str, experiment_id: str, session: AsyncSession) -> dict:
    """Mark a job as FAILED due to remote command crash."""
    end_time_str = time.strftime("%Y-%m-%d %H:%M:%S", time.gmtime())
    await job_update_job_data_insert_key_value(job_id, "end_time", end_time_str, experiment_id)
    await job_update_status(job_id, "FAILED", experiment_id=experiment_id, session=session)
    return {"status": "FAILED", "end_time": end_time_str}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/routers/compute_provider.py` around lines 1673 - 1702,
Extract the inline crash-handling block into a new async helper in job_service
(e.g., async def mark_job_as_crashed(job_id: str, experiment_id: str, session:
AsyncSession) -> dict) that performs the end_time formatting, calls
job_update_job_data_insert_key_value(job_id, "end_time", end_time_str,
experiment_id) and job_update_status(job_id, "FAILED",
experiment_id=experiment_id, session=session), commits the session and returns a
standardized result (status, end_time); then replace the router's live_status ==
"crashed" branch to call job_service.mark_job_as_crashed(job_id,
job.get("experiment_id"), session), handle exceptions similar to current code
(logging the exception and returning the same error dict), and ensure the router
returns the same success payload when the service reports success.