Merge branch 'main' into bump/matplotlib-3.11.0

Author: dadmobile

.agents/skills/transformerlab-cli/SKILL.md

@@ -762,7 +762,7 @@ Also note that secrets passed inside `--config` (e.g. `api_token`, `azure_client
 9. **`job task-logs --follow`** streams continuously and blocks until the job finishes — use when the user wants real-time monitoring
 10. **Never use the deprecated `lab job logs`** — see the "Job logs: three real commands" section below.
 11. **Before queuing a task, CONFIRM the experiment with the user.** Run `lab config` to read the current default and `lab --format json experiment list` to verify it exists, then ask: "I'm about to queue this under experiment `<name>` (your current default). OK, or pick another?" Show 2–3 alternatives from `experiment list` if the current one looks stale or missing. Skip the confirmation only when the user has already named the experiment in this turn.
-12. **After queuing a task, ASK the user if they'd like you to watch the logs.** Don't start streaming or polling automatically — jobs can take minutes to hours, and `--follow` blocks. Report the Job ID and ask: "Want me to watch the logs and report back?"
+12. **After queuing a task, ASK the user if they'd like you to watch the logs.** Don't start streaming or polling automatically — jobs can take minutes to hours, and `--follow` blocks. Report the Job ID and ask: "Want me to watch the logs and report back?" If they say yes and your harness can self-schedule (e.g. Claude Code's `ScheduleWakeup`), watch by checking once per turn and scheduling the next check — not a blocking `--follow` or a `while`/`sleep`/background poll loop, which can strand the session with a finished job (see workflows.md "Polling Pattern for Agents").
 13. **Never create API keys programmatically** — if auth fails, ask the user to provide an API key from the web UI
 14. **Always pass `--description/-m` when queuing a task. Generate it yourself — never ask the user.** See "Always write a run description" below.
 

.agents/skills/transformerlab-cli/references/autoresearch.md

@@ -250,6 +250,7 @@ The agent loops autonomously. Never ask "should I continue?" — keep going unti
 6. **Advance.** What this means depends on parallelism:
    - **N = 1 (sequential):** wait for the just-queued job to finish, then go to step 7. Poll with `lab --format json job list --running`.
    - **N ≥ 2 (parallel / fire-and-advance):** **do not wait.** Return to step 0 and pick the next idea immediately, until `RUNNING >= N`. Only block when the queue is full. This is what enables grid-style search; waiting after every queue collapses parallelism back to 1.
+   - **How to "wait" / "block" without stranding the session:** don't hold the turn open with a `while`/`sleep` or `run_in_background` poll loop — on remote providers the harness can't track the job, so a loop that ends before the job finishes leaves the session idle until a manual nudge. If your harness can self-schedule (e.g. Claude Code's `ScheduleWakeup`), do **one** `lab job list --running` / `job info` check, then schedule the next check and end the turn, repeating until a job is terminal. The bare poll loop is the fallback for scripts/cron and agents without self-scheduling.
 7. **Score → keep or discard** any *completed* jobs whose results haven't been processed yet. In parallel mode, this means scanning recently-finished jobs at the start of each cycle, not just the one you queued last.
    ```bash
    # Find COMPLETE jobs we haven't acted on yet (no discard flag set, not the current best).

.agents/skills/transformerlab-cli/references/workflows.md

@@ -188,6 +188,13 @@ lab --format json job info JOB_ID
 
 ### Polling Pattern for Agents
 
+> **Interactive agents: prefer your harness's scheduler over this loop.** The `while`/`sleep`
+> loop below blocks a whole turn, and run in the background it can be orphaned by a user
+> message — either way it can leave the session idle with a finished job unnoticed. If your
+> harness can self-schedule a wake (e.g. Claude Code's `ScheduleWakeup`), do **one** `lab job
+> info` check per turn, then schedule the next check and end the turn, repeating until terminal.
+> The blocking loop below is the fallback for scripts, cron, and agents without self-scheduling.
+
 When monitoring a job programmatically, use this pattern:
 
 ```bash

.agents/skills/transformerlab-cli/templates/queue-and-monitor.sh

@@ -2,6 +2,10 @@
 # Template: Queue a task and monitor until completion
 # Queues a task non-interactively, polls for job completion, and downloads results.
 #
+# NOTE: this blocking poll loop is for scripts/cron. An interactive agent should NOT run it
+# in-session — a self-scheduling harness (e.g. Claude Code's ScheduleWakeup) should check once
+# per turn and reschedule instead, so a finished job can't strand the session.
+#
 # Usage: ./queue-and-monitor.sh <task_id> [output_dir]
 #
 # Arguments:

.github/workflows/prettier.yml

@@ -23,8 +23,10 @@ jobs:
         with:
           node-version: "22"
 
+      # Must match the prettier version in package.json devDependencies,
+      # or local `npm run format` and this check will disagree.
       - name: Install Prettier
-        run: npm install -g prettier@3.8.3
+        run: npm install -g prettier@3.9.4
 
       - name: Check Prettier formatting
         run: npm run format:check

api/api.py

@@ -217,12 +217,12 @@ async def lifespan(app: FastAPI):
             integrations=[FastApiIntegration()],
             # Enable sending logs to Sentry
             enable_logs=True,
-            # Set traces_sample_rate to 1.0 to capture 100%
-            # of transactions for tracing.
-            traces_sample_rate=1.0,
-            # Set profile_session_sample_rate to 1.0 to profile 100%
-            # of profile sessions.
-            profile_session_sample_rate=1.0,
+            traces_sample_rate=float(os.getenv("SENTRY_TRACES_SAMPLE_RATE", "1.0")),
+            # The profiler samples frames across threads, which can segfault the
+            # interpreter on Python 3.11 (frame_getback race, e.g.
+            # https://github.com/getsentry/sentry-python/issues/2386), so it is
+            # off unless explicitly enabled.
+            profile_session_sample_rate=float(os.getenv("SENTRY_PROFILE_SESSION_SAMPLE_RATE", "0.0")),
             # Set profile_lifecycle to "trace" to automatically
             # run the profiler on when there is an active transaction
             profile_lifecycle="trace",

api/run.sh

@@ -127,6 +127,10 @@ fi
 # Temporary: Turn off python buffering or debug output made by print() may not show up in logs
 export PYTHONUNBUFFERED=1
 
+# Print the Python traceback of the crashing thread if the interpreter dies on a
+# fatal signal (e.g. segfault), so crashes are diagnosable from the service logs
+export PYTHONFAULTHANDLER=1
+
 UVICORN_WORKERS=${TFL_UVICORN_WORKERS:-1}
 
 echo "▶️ Running one-time startup tasks before workers"

api/transformerlab/services/job_service.py

@@ -842,7 +842,7 @@ async def get_artifacts_from_sdk(job_id: str, experiment_id: str) -> Optional[Li
             return None
 
         sdk_job = Job(job_id, experiment_id)
-        artifact_paths = sdk_job.get_artifact_paths()
+        artifact_paths = await sdk_job.get_artifact_paths()
 
         if not artifact_paths:
             return None

cli/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "transformerlab-cli"
-version = "0.0.67"
+version = "0.0.68"
 description = "Transformer Lab CLI"
 requires-python = ">=3.10"
 authors = [{ name = "Transformer Lab", email = "hello@transformerlab.ai" }]