feat: Quick Deploy button in model tab with scope selection and Run History integration

[abhizipstack]

What

Model Tab — Quick Deploy

• Primary Quick Deploy button added to the model tab action row (next to Clear / Download CSV / Reveal Sequence), with a dropdown chevron that shows recent runs.
• Click → fetches candidate jobs for this model → modal flow:
  • 0 candidates → "No Deployment Job Found" with a CTA linking to the Scheduler page.
  • 1 candidate → confirm modal showing job + environment.
  • 2+ candidates → job picker radio group above.
• Modal shows two scope cards (Run this model only / Run full job) — visual selection, does NOT auto-trigger.
• "I understand…" confirmation checkbox (gated on scope selection) — dynamic text reflects the chosen scope, job name, environment, and model count.
• Run button in the footer ("Run model" / "Run full job") — disabled until job selected + scope selected + checkbox ticked.
• Success/error toast with job + env summary; explorer refresh after dispatch.
• Dropdown chevron opens a recent-runs popup (last 5 runs for this model, mixed scheduled + manual) with theme-aware styling, relative timestamps, and a "View full Run History →" link.

Run History — Trigger + Scope taxonomy

• Replaced the single "Source" column with two columns: Trigger (Manual / Scheduled) and Scope (Full job / Single model with model names).
• Two composable filters (Trigger + Scope) replace the old Source filter. Both work with Status.
• Back-compat: old rows with kwargs.source === "quick_deploy" render correctly as Manual + Single model.
• Expanded error row anchored to parent row: red left-border stripe runs through both, transparent row border in between, collapse by default.

Jobs List

• Run icon tooltip updated to "Deploy Job" for naming consistency.

Backend

• trigger_scheduled_run gains models_override: list and trigger: str kwargs. When models_override is set, scopes the DAG run to those models via execute_visitran_run_command(current_models=...). Records trigger ("manual" / "scheduled") and scope ("model" / "job") on TaskRunHistory.kwargs for every run (including retries).
• trigger_task_once refactored into shared _dispatch_task_run helper (Celery-first with sync fallback) used by both the existing full-job trigger and the new single-model trigger.
• New endpoints:
  • POST /jobs/trigger-periodic-task/<task_id>/model/<model_name> — validates the model is enabled on the job, dispatches a scoped run.
  • GET /jobs/quick-deploy/candidates/<model_name> — returns jobs in the project that include the model with enabled_model_count.
  • GET /jobs/quick-deploy/recent-runs/<model_name>?limit=5 — returns recent runs for any job that includes this model, with trigger/scope/models_override and back-compat.

Why

Users had no way to deploy a model from the model tab — they had to navigate to the Jobs List and trigger the whole job. This feature lets users deploy the current model (or the full job) with a clear scope-selection and confirmation flow, directly from where they're editing.

The Run History taxonomy was conflating trigger type (manual vs scheduled) with scope (model vs job), making it impossible to filter "show me only the runs I manually kicked off" or "only single-model deploys".

How

• Frontend (no-code-model.jsx): useJobService hooks for listDeployCandidates, runTaskForModel, runTask, listRecentRunsForModel. Modal state machine with step (loading/empty/confirm/pick), selectedScope (model/job), and confirmed (checkbox). Space.Compact with Dropdown for the recent-runs popup. All using antd theme tokens.
• Frontend (Runhistory.jsx): getRunTriggerScope helper with back-compat for legacy kwargs.source. CSS .runhistory-row-expanded + .ant-table-expanded-row overrides to bind parent-child rows visually. onRow injects red box-shadow on expanded parents.
• Backend (celery_tasks.py): trigger_scheduled_run computes scope from models_override, passes trigger through to TaskRunHistory.kwargs and the retry path.
• Backend (views.py): _dispatch_task_run centralizes Celery dispatch + sync fallback; list_deploy_candidates filters model_configs by model name; list_recent_runs_for_model queries across all jobs containing the model.

Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

Low risk:

• Backend endpoints are additive — new URL routes alongside existing ones. trigger_task_once is refactored to use _dispatch_task_run but its external behavior is identical (same request/response shape).
• trigger_scheduled_run gains optional kwargs with defaults that preserve existing Celery beat behavior (trigger="scheduled", models_override=None).
• TaskRunHistory.kwargs now includes trigger and scope on every new run. Old rows lack these; the frontend falls back to legacy kwargs.source handling or defaults ("scheduled" / "job"). No migration needed.
• Run History expand behavior widens from FAILURE-only to all completed runs. The FAILURE path is preserved (error_message Alert, scrollable pre). SUCCESS rows that were not expandable now are — no known consumer relies on them being non-expandable.
• Jobs List tooltip text changes from "run" to "Deploy Job" — cosmetic only.

Database Migrations

None. trigger, scope, and models_override live in the existing TaskRunHistory.kwargs JSONField.

Env Config

None.

Relevant Docs

None.

Related Issues or PRs

• PR feat: Deploy, Jobs & Run History UX improvements #61 — Deploy, Jobs & Run History UX improvements (separate branch, complementary but independent; can merge in either order with minor conflict resolution on Runhistory.jsx)

Dependencies Versions

No changes.

Notes on Testing

Tested locally (host-mode: Django runserver + Celery worker/beat + React dev server, Postgres + Redis via Docker):

1. Quick Deploy — 0 candidates: opened a model with no scheduled job → "No Deployment Job Found" modal → "Go to Scheduler" navigated correctly.
2. Quick Deploy — 1 candidate: opened model included in one job → confirm modal showed job + env → selected scope "Run this model only" → ticked checkbox → "Run model" button enabled → clicked → toast "Deploy Triggered" appeared, setRefreshModels called.
3. Quick Deploy — scope "Run full job": selected "Run full job" card → checkbox text updated to show all N models → button label flipped to "Run full job" → dispatched via runTask.
4. Recent-runs popup: clicked chevron → popup showed last 5 runs with Manual/Scheduled tag, scope tag, relative time, job name + env → "View full Run History →" navigated correctly.
5. Run History — Trigger/Scope columns: verified Manual + Single model for quick-deploy runs, Scheduled + Full job for cron runs. Filters compose correctly.
6. Run History — error anchor: expanded FAILURE row → red stripe from parent through expanded panel, transparent border between. Collapsed by default on data load. Dark mode verified.
7. Back-compat: old kwargs.source="quick_deploy" rows rendered as Manual + Single model.

Screenshots

I have read and understood the Contribution Guidelines.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR adds a Quick Deploy button to the model tab (scope selection, confirmation checkbox, recent-runs popup) and splits Run History's single "Source" column into composable Trigger + Scope filters, backed by three new Django endpoints and extended trigger_scheduled_run kwargs. Prior reviewer feedback on null environment, stale cache, missing DB filter, and enabled_model_count null safety has all been addressed in follow-up commits.

Confidence Score: 5/5

Safe to merge; all prior P1 issues resolved, remaining findings are P2 edge cases

All previous reviewer concerns (null env, stale cache, missing DB filter, enabled_model_count null safety) have been addressed. Remaining findings are P2: an AttributeError on non-dict truthy cfg values (unlikely in practice, same class as the already-fixed null case) and a benign double-fetch race in the dropdown guard. Backend endpoints are additive, Celery kwargs are backward-compatible, and the Run History taxonomy is cleanly back-compat.

backend/backend/core/scheduler/views.py — cfg.get() guards in list_deploy_candidates and trigger_task_once_for_model should use isinstance(cfg, dict) for consistency with the enabled_model_count fix

Important Files Changed

Filename	Overview
backend/backend/core/scheduler/views.py	Adds _dispatch_task_run helper + three new endpoints; non-dict truthy cfg values are not guarded in list_deploy_candidates and trigger_task_once_for_model (AttributeError risk)
backend/backend/core/scheduler/celery_tasks.py	Adds models_override/trigger kwargs with safe defaults; retry path correctly propagates both; scope is recomputed at entry so no extra kwarg needed
backend/backend/core/scheduler/urls.py	Additive URL registration for three new endpoints; correct path patterns and names
frontend/src/ide/editor/no-code-model/no-code-model.jsx	Adds Quick Deploy modal flow, recent-runs popup, log-level filter, and socket cleanup fix; dedup guard in fetchRecentRuns allows duplicate in-flight requests
frontend/src/ide/run-history/Runhistory.jsx	Replaces Source column with Trigger + Scope, adds two composable filters, moves getRunTriggerScope to module scope; auto-expand correctly keyed to backUpData
frontend/src/ide/run-history/RunHistory.css	CSS overrides to visually bind expanded error rows to their parent; clean and non-breaking
frontend/src/ide/scheduler/JobListTable.jsx	Tooltip text updated from 'run' to 'Deploy Job'; cosmetic-only change
frontend/src/ide/scheduler/service.js	Three new service methods (runTaskForModel, listDeployCandidates, listRecentRunsForModel) with correct encodeURIComponent usage

Sequence Diagram

sequenceDiagram
    participant U as User (model tab)
    participant FE as no-code-model.jsx
    participant SVC as service.js
    participant BE as views.py
    participant CL as Celery
    participant DB as TaskRunHistory

    U->>FE: Click Quick Deploy
    FE->>SVC: listDeployCandidates(projectId, modelName)
    SVC->>BE: GET /jobs/quick-deploy/candidates/{model}
    BE-->>FE: candidates[]

    alt 0 candidates
        FE-->>U: No Deployment Job Found modal
    else 1 candidate
        FE-->>U: confirm modal (job + env)
    else 2+ candidates
        FE-->>U: job picker radio + confirm modal
    end

    U->>FE: Select scope + tick checkbox + Run
    alt scope = model
        FE->>SVC: runTaskForModel(projectId, taskId, modelName)
        SVC->>BE: POST /jobs/trigger-periodic-task/{id}/model/{model}
    else scope = job
        FE->>SVC: runTask(projectId, taskId)
        SVC->>BE: POST /jobs/trigger-periodic-task/{id}
    end

    BE->>BE: _dispatch_task_run(task, userId, models_override?)
    BE->>CL: apply_async(trigger=manual, models_override?)
    CL->>DB: TaskRunHistory.create(trigger, scope, models_override)
    BE-->>FE: success
    FE-->>U: toast + refresh

    U->>FE: Click chevron dropdown
    FE->>SVC: listRecentRunsForModel(projectId, modelName, 5)
    SVC->>BE: GET /jobs/quick-deploy/recent-runs/{model}
    BE-->>FE: runs[] with trigger/scope back-compat
    FE-->>U: Recent runs popup

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: backend/backend/core/scheduler/views.py
Line: 775-776

Comment:
**Non-dict truthy config causes `AttributeError`**

`not cfg` short-circuits for `None` and `{}`, but for any other truthy non-dict value (e.g. a JSON boolean `true` stored as `model_configs["my_model"] = True`), `not cfg` is `False` and `cfg.get("enabled", True)` raises `AttributeError`. The previous null-safety fix already established the right pattern — `isinstance(m_cfg, dict)` is used in `enabled_model_count` on line 780 but not here.

The same gap exists in `trigger_task_once_for_model` (line 696).

```suggestion
        if not isinstance(cfg, dict) or not cfg.get("enabled", True):
```

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/backend/core/scheduler/views.py
Line: 695-696

Comment:
**Non-dict truthy config causes `AttributeError`**

Same issue as in `list_deploy_candidates` line 776: `not model_cfg` short-circuits for `None`/`{}` but not for other truthy non-dict values. If `model_cfg` is, say, a JSON boolean `True`, `not model_cfg` is `False` and `model_cfg.get("enabled", True)` raises `AttributeError`. The `enabled_model_count` sibling check already uses `isinstance(m_cfg, dict)` as the guard.

```suggestion
    if not isinstance(model_cfg, dict) or not model_cfg.get("enabled", True):
```

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/ide/editor/no-code-model/no-code-model.jsx
Line: 1678

Comment:
**Dedup guard doesn't cover in-flight fetches**

The early-return only fires when `!loading`. If the user opens the chevron dropdown while a fetch is already in progress (`loading === true`), the condition evaluates to `false` and a second concurrent request is dispatched. The two responses will race to set state; the final value is correct but the extra request is wasteful.

```suggestion
    if (recentRunsState.loading || recentRunsState.fetchedFor === name) return;
```

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

_{Reviews (4): Last reviewed commit: "fix: address reviewer feedback — null co..." | Re-trigger Greptile}

[wicky-zipstack]

Changes requested (small, mostly polish):

1. Dedupe formatRelativeTime (no-code-model.jsx) → use shared getRelativeTime.
2. Keep auto-expand on FAILURE in Run History — current behaviour is a regression.
3. Gate the red boxShadow on record.status === "FAILURE", or colour-match by status.
4. (Coordinate with feat: Deploy, Jobs & Run History UX improvements #61) Pull getRunTriggerScope/getRunInsights into one shared util.

[wicky-zipstack]

@abhizipstack One small leftover (non-blocking, can ship): the inline boxShadow: inset 3px 0 0 0 ${token.colorError} on onRow is still applied to any expanded row regardless of status. Auto-expand is now FAILURE-only so it's fine in practice, but if a user manually expands a SUCCESS/RETRY row they'll get a misleading red bar. Worth a follow-up to gate on record.status === "FAILURE" or color-match by status.

[tahierhussain]

LGTM