Generated banner for Spark CLI
Generated logo for Spark CLI

Spark CLI

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk

From the author

Manages Fabric Spark work, including notebook cell code with %%configure, %%sql, PySpark and notebookutils, named notebook runs, Livy sessions, triage of failed or OOM notebook and pipeline Spark runs, and the Materialized Lake View (MLV) lifecycle. Load it before writing MLV SQL, since CREATE MATERIALIZED LAKE VIEW and its CONSTRAINT clause are Fabric-only. KQL materialized views belong to eventhouse-cli.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

spark-cli is a mode-based dispatcher designed to handle the full lifecycle of Fabric Spark operations. It provides structured guidance for authoring notebook code, managing interactive Livy sessions, diagnosing Spark job failures, and operating Materialized Lake Views (MLV). The skill enforces strict operational boundaries, requiring users to select a specific mode (authoring, consumption, operations, or mlv) and consult the corresponding reference documentation before executing any commands to ensure correct API usage and payload construction.

What it does

  • Authors and manages Fabric notebook cell code including PySpark, Scala, and %%sql.
  • Facilitates interactive data analysis through Livy session management.
  • Diagnoses failed, slow, or OOM Spark jobs and pipeline runs.
  • Manages the complete lifecycle of Materialized Lake Views, including definition, scheduling, and refresh monitoring.
  • Provides standardized patterns for data engineering, schema management, and error handling in Fabric.
  • Ensures proper telemetry and authentication for all Fabric API interactions.

When to use it

  • When writing or updating code within Fabric notebooks.
  • When performing ad-hoc data analysis using interactive Livy sessions.
  • When investigating performance bottlenecks or failures in Spark jobs.
  • When creating, scheduling, or troubleshooting Materialized Lake Views.
  • When you need to ensure your Fabric API calls follow mandatory telemetry and authentication standards.

Advantages

  • Provides a structured, mode-based approach to prevent configuration errors.
  • Centralizes complex Spark and MLV management tasks into a single interface.
  • Enforces best practices for data engineering and schema management.
  • Reduces ambiguity by clearly defining the scope of Spark-related operations versus other CLI tools.

Usage examples

“Write a notebook cell that reads a bronze table and writes a silver Delta table.”
The agent enters 'authoring' mode, reads the relevant reference, and generates the appropriate PySpark code using Delta Lake patterns.
“My notebook run failed with an OOM error, can you help me diagnose it?”
The agent enters 'operations' mode, reads the diagnostic workflow reference, and guides the user through analyzing the job logs and metrics.
“Schedule a nightly refresh for the lakehouse MLV and show me its run history.”
The agent enters 'mlv' mode, reads the MLV reference, and executes the necessary API calls to configure the schedule and retrieve the history.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/spark-cli/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip spark-cli.zip -d .agents/skills

Documentation by Microsoft

Telemetry — MANDATORY. Every api.fabric.microsoft.com call must carry x-ms-fabric-skill: spark-cli (az rest: --headers "x-ms-fabric-skill=spark-cli"), including every LRO poll, fabric_lro and retry. Snippets omit it — add it anyway.

CRITICAL NOTES

  1. To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering

  2. To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering

  3. Skill disambiguation: use spark-cli for notebook cell code (including %%sql cells), named notebook runs, Livy sessions, Spark failure triage, and everything about a Materialized Lake View -- writing the definition, reviewing a query for incremental-refresh readiness, and scheduling, refreshing, monitoring or diagnosing an existing one. A KQL materialized view in an Eventhouse is eventhouse-cli; plain read-only T-SQL against a Warehouse or Lakehouse SQL endpoint is sqldw-cli.

  4. Hard routing boundary: never execute an Eventhouse/KQL materialized-view request from this skill. Route it to eventhouse-cli; if that skill is unavailable, state that the request cannot be completed in the current skill context and stop without calling Fabric APIs or creating artifacts.

Fabric Spark and Materialized Lake Views -- CLI Skill

This one skill owns Fabric Spark: notebook cell authoring, notebook runs, Livy-session analysis, Spark failure diagnostics, and the whole Materialized Lake View lifecycle.

It is a mode dispatcher and contains NO procedures. Pick the mode that matches the request from the table below, then read the matching references/<mode>.md file end to end with your file-reading tool BEFORE issuing a single command. That file holds the endpoints, payload shapes, templates and gotchas; acting without it produces wrong payloads and wrong results.

Mode selection

ModeUse when the request ...Example triggersRead this first
authoringwrites notebook cell code (PySpark, Scala, SparkR, %%sql, %%configure), runs a notebook by name and reports a NORMAL run status, or authors a Materialized Lake View definition or reviews an MLV query for incremental-refresh readinesswrite notebook code, notebook cell code, %%sql cell, run notebook, execute notebook, notebookutils, create materialized lake view, is this MLV query incremental-refresh readyreferences/authoring.md
consumptionruns interactive ad-hoc PySpark in a Lakehouse Livy session -- never a notebookcreate a Livy session, run calculation in Livy, PySpark, DataFrame analysis, join tables across lakehouses, Delta time-travelreferences/consumption.md
operationsdiagnoses a FAILED, unhealthy, throttled or slow Spark notebook / pipeline / Livy runfailed notebook, Spark Livy health, Spark OOM, why is my notebook slow, job diagnostics, 430 throttlingreferences/operations.md
mlvdiscovers or operates EXISTING Materialized Lake Views: Spark SQL discovery, refresh schedules, on-demand refresh, run history, cancellation, and refresh-failure classificationdiscover MLVs, list materialized lake views, schedule MLV, MLV run history, cancel refresh, trigger MLV refresh, diagnose MLV refresh failurereferences/mlv.md
Mode boundary rule

Mode is decided by the artefact and the outcome, not by the language. A notebook cell is always authoring even when the cell is %%sql. A Livy session is always consumption. A Spark run that FAILED or is unhealthy is operations; a run that succeeded is reported by authoring. For a Materialized Lake View the VERB decides: writing or reviewing the definition is authoring, while discovering, scheduling, refreshing, monitoring or diagnosing existing MLVs is mlv. If discovery must be executed, switch to consumption for Livy or authoring for a notebook only after reading the discovery command from references/mlv.md.

If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.

Terminal write -- the step you must not skip

Reading the reference and planning the change is NOT completing the task. Each mutating mode ends with one state-changing call. If you did not issue it, nothing was persisted -- say so explicitly rather than reporting success.

ModeTerminal write
authoringfor an EXISTING notebook, POST .../notebooks/{id}/updateDefinition to save the cell; a NEW notebook needs POST /v1/workspaces/{ws}/items first; for a run request, trigger the job via the Jobs API. Printing cell code into the chat is not saving or running it.
consumptionnone -- this mode is read-only
operationsnone -- this mode is read-only
mlvPOST /v1/workspaces/{ws}/lakehouses/{lakehouse}/jobs/refreshMaterializedLakeViews/instances for an on-demand refresh, or the schedule create/update/delete call for a scheduling request. Reporting what the schedule would be is not creating it.

Before you report the task done, confirm the terminal call returned success and, where the reference documents a readback, read the artefact back to prove the change landed.

Shared essentials (all modes)

Resolve the workspace and item first; every mode depends on it.

TaskReferenceNotes
Finding Workspaces and Items in FabricCOMMON-CLI.mdMandatory -- read before resolving any workspace or item id
Fabric Topology & Key ConceptsCOMMON-CORE.mdItem types, workspaces, capacities
Environment URLsCOMMON-CORE.mdSovereign / non-public cloud hosts
Authentication & Token AcquisitionCOMMON-CORE.mdWrong audience = 401; read before any auth issue
Authentication RecipesCOMMON-CLI.mdaz login flows and token acquisition
Core Control-Plane REST APIsCOMMON-CORE.mdPagination, LRO polling, rate limiting
Gotchas & TroubleshootingCOMMON-CLI.mdaz rest audience, shell escaping, token expiry

Rules

MUST
  • Select exactly one mode from the table above before doing anything else.

  • Treat vague requests such as "set up my data" as insufficiently scoped. Ask what artefact, source, destination, and outcome the user wants; never infer intent by finding and running an existing notebook or job.

  • Read references/<mode>.md end to end, as your FIRST tool call, before the first command of that mode. Read it ONCE, in a single full read: do not re-open it, do not grep it again, and do not page through it. You already have it.

  • Apply the same read-once discipline to every other file you load, including nested references/<mode>/*.md sub-references and shared common/*.md files: open only the ones you actually need, read each ONCE end to end, and never grep or re-open one you already loaded.

  • Resolve workspace and item ids by listing and filtering, never by guessing a GUID.

  • Stop after routing any Eventhouse/KQL materialized-view request. Unavailable sibling skills are a blocking boundary, not permission to implement their workload directly.

  • Announce a mode switch explicitly when the request crosses a boundary.

  • Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented commands against the live workspace and report the real results. Quoting what the reference says instead of executing it does not answer the request.

PREFER
  • The narrowest mode that satisfies the request.

  • Reading exactly ONE mode reference. Load a second only when the request genuinely spans modes, and say so before you do.

  • Reporting the mode you chose in your first response so the user can correct you.

AVOID
  • Acting from this dispatcher alone -- it intentionally omits the operational detail.

  • Answering with a summary of the reference instead of executing it.

  • Re-reading or re-grepping a reference you already loaded; it costs turns and tokens.

  • Mutating anything while in a read-only mode.

  • Loading a different skill for work this family already owns (see CRITICAL NOTES 3).

  • Attempting an out-of-scope request through raw REST calls when the owning skill is unavailable. Name the owning skill and stop; do not improvise by creating Fabric artefacts outside spark-cli's scope.

Examples

User requestModeReference to read
"Write a notebook cell that reads the bronze table and writes a silver Delta table."authoringreferences/authoring.md
"Create a Livy session and count the distinct customers in the lakehouse."consumptionreferences/consumption.md
"My notebook run failed with an OOM -- work out why."operationsreferences/operations.md
"Is this materialized lake view query ready for incremental refresh?"authoringreferences/authoring.md
"Show me the Spark SQL command that lists the MLVs in schema silver."mlvreferences/mlv.md
"Schedule a nightly refresh for the lakehouse MLV lineage and show me its run history."mlvreferences/mlv.md

Files

references/operations/pipeline-diagnosis.md

Pipeline Run Diagnosis

When the user provides a pipeline name or ID with a pipeline run ID (job instance ID), auto-discover all Spark-related activities and diagnose each one.

Trigger examples:

  • "Diagnose pipeline ETL_Pipeline run abc-123"

  • "My pipeline failed, run ID is abc-123"

  • "Check all Spark jobs in pipeline run abc-123"

Step P1 — Resolve Pipeline & Get Run Status

# Resolve pipeline item ID (if user gave name)
pipelineId=$(az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/items?type=DataPipeline" \
  --query "value[?displayName=='<PipelineName>'].id" --output tsv)

# Get pipeline run status
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/items/$pipelineId/jobs/instances/$jobInstanceId" \
  --output json

Response includes: id, status (Completed/Failed/InProgress/Cancelled), startTimeUtc, endTimeUtc, failureReason.

Step P2 — Query Activity Runs

Use the public queryActivityRuns API to get all activities within the pipeline run. This returns activity details including Spark session IDs, notebook item IDs, parameters, error details, and tracebacks — everything needed for diagnosis.

API endpoint (docs):

POST $FABRIC_API_URL/workspaces/$workspaceId/datapipelines/pipelineruns/$jobInstanceId/queryactivityruns

Shell escaping: In PowerShell, inline JSON bodies for az rest must use escaped double quotes inside double-quoted strings ("{"key\":"value\"}") or use a --body @file.json approach. Single-quoted strings with inner double quotes ('{"key":"value"}') work correctly in PowerShell but may fail if the shell double-processes escapes.

PowerShell & in URLs: The & character in URL query parameters (e.g., ?type=driver&fileName=stderr) is interpreted as PowerShell's call operator, breaking the URL. For Spark Monitoring endpoints that require multiple query params, write the URL to a variable first or use --url-parameters:

# BROKEN: PowerShell treats & as call operator
az rest --url "https://...?type=driver&fileName=stderr"

# WORKAROUND: Use a JSON body file or single-param endpoints when possible
# The Spark Monitoring jobs, advice, stagesSummary, and resourceUsage endpoints
# require NO query params — prefer these over log download endpoints.
# Bash — use heredoc or file
cat > /tmp/query-body.json << 'EOF'
{
  "filters": [],
  "orderBy": [{"orderBy": "ActivityRunStart", "order": "DESC"}],
  "lastUpdatedAfter": "<pipeline startTimeUtc minus 1 hour>",
  "lastUpdatedBefore": "<pipeline endTimeUtc plus 1 hour, or now if InProgress>"
}
EOF
az rest --method post --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/datapipelines/pipelineruns/$jobInstanceId/queryactivityruns" \
  --body @/tmp/query-body.json --output json
# PowerShell — escape inner double quotes with backslash
az rest --method post --resource $FABRIC_RESOURCE_SCOPE `
  --url "$FABRIC_API_URL/workspaces/$workspaceId/datapipelines/pipelineruns/$jobInstanceId/queryactivityruns" `
  --body '{\"filters\":[],\"orderBy\":[{\"orderBy\":\"ActivityRunStart\",\"order\":\"DESC\"}],\"lastUpdatedAfter\":\"<startTimeUtc minus 1h>\",\"lastUpdatedBefore\":\"<endTimeUtc plus 1h>\"}' `
  --output json

Response schema — paginated { continuationToken, value: [...] }:

FieldDescription
value[].activityNameActivity name (e.g., "Check Load")
value[].activityTypeTridentNotebook, SparkJob, Copy, ExecutePipeline, etc.
value[].statusSucceeded, Failed, Inactive, Cancelled
value[].iterationHashUnique per ForEach iteration — different hashes = loop iterations
value[].retryAttemptRetry count (null if no retries)
value[].input.notebookIdNotebook item ID — use directly for Spark Monitoring API calls
value[].input.workspaceIdWorkspace ID for the notebook (may differ for cross-workspace)
value[].input.parametersPipeline parameters passed to the notebook
value[].output.result.sessionIdLivy session ID — use directly with Spark Monitoring APIs
value[].output.result.runStatusSucceeded / Failed
value[].output.result.error{ ename, evalue, traceback[] } — full Python traceback
value[].output.result.highConcurrencyModeStatusnull or HC status
value[].output.result.metadata.runStartTimeActual Spark execution start
value[].output.result.metadata.runEndTimeActual Spark execution end
value[].output.SparkMonitoringURLRelative URL to Fabric Spark Monitor UI
value[].output.executionDurationRuntime in seconds
value[].error{ errorCode, message, failureType, target } — pipeline-level error
continuationTokenIf present, pass as query param to get next page

Key insight: The queryActivityRuns response provides both input.notebookId and output.result.sessionId directly — no need to decode the pipeline definition to build an activity→item map. The input.notebookId is the item ID needed for all Spark Monitoring API calls.

Error API priority for pipeline runs — richest to leanest:

PrioritySourceError fieldsNotes
1queryActivityRuns output.result.errorename, evalue, traceback[] (cell + line number)Most detailed — always try first
2queryActivityRuns errorerrorCode, message, failureType (UserError/SystemError)Pipeline-level error (e.g., timeout, dependency)
3Spark Advisor (/advice)TaskError.name, description, fix recommendationSpark-infrastructure failures (OOM, skew)
4Driver stderr (/logs?type=driver&fileName=stderr)Raw Java/Python stack tracesWhen traceback is absent or points to Spark internals
5Job Instance (/jobs/instances/{id})failureReason (high-level string)Quick triage only — often too vague

Use queryActivityRuns first — it has the longest data retention and returns structured error data. Spark Monitoring APIs (Advisor, logs) have shorter TTL and may return 404 for older runs.

Step P3 — Identify Spark Activities & Handle Edge Cases

Filter activities by type to find Notebook and Spark Job Definition activities:

activityType valueItem typeContains Spark session
TridentNotebookFabric NotebookYes
SparkJobSpark Job DefinitionYes
DataflowV2Dataflow Gen2Sometimes (if Spark engine)
ExecutePipelineChild pipelineRecurse (see below)

Skip non-Spark activities (e.g., Wait, Copy, SetVariable, ForEach, IfCondition, Until) for diagnostic analysis.

Edge case handling:

CaseDetectionAction
ForEach / loop iterationsMultiple runs with same activityName but different iterationHashDiagnose each iteration separately; group in report by activity name + iteration
Retry attemptsretryAttempt > 0Diagnose only the latest attempt (highest retryAttempt value per activity); mention earlier attempts failed
Nested pipelinesactivityType == "ExecutePipeline"Extract the child pipeline's jobInstanceId from output and recurse — re-run Steps P1–P6 on the child pipeline
Cancelled downstreamstatus == "Cancelled" and activity has no output.result.sessionIdReport as "Cancelled — no Spark session (likely due to upstream failure)"; do not attempt Spark diagnostics
Null sessionIdoutput.result.sessionId == null or output is emptySpark never started — report the error field from the activity; common cause: environment setup failure or library install error
Cross-workspace notebookinput.workspaceId differs from pipeline's workspaceUse the notebook's input.workspaceId for Monitoring API calls (user must have Viewer access on that workspace)
High-concurrency modeoutput.result.highConcurrencyModeStatus is present and not null/NoneThe sessionId maps to a shared Livy session serving multiple notebooks concurrently. Diagnostics (stages, executors, resource usage) reflect all notebooks in that session, not just this activity. Note this in the report: "HC session — metrics are aggregated across N notebooks". Consider filtering Spark jobs by time window (activityRunStart–activityRunEnd) to isolate this activity's contribution.
Inactive activitiesstatus == "Inactive"Activity was disabled in the pipeline; skip entirely. output.state will say "Inactive" and output.message confirms it was skipped.

Deduplication for ForEach:

# Group activities by activityName
# For each group:
#   If all have same iterationHash → single run (no loop)
#   If different iterationHash values → ForEach loop
#     → Diagnose each iteration
#     → In report, show: "Activity: LoadRawData [iteration 1/5] (Failed)"

Deduplication for retries:

# Group activities by activityName + iterationHash
# For each group:
#   Keep only the run with max(retryAttempt)
#   Note: "Activity retried N times; analyzing final attempt"

Step P4 — Extract Spark Session IDs from Activity Output

For each Notebook/SJD activity found in Step P3, the output and input fields from queryActivityRuns contain everything needed for Spark diagnostics:

Key fields from queryActivityRuns response:

FieldDescriptionUse
input.notebookIdNotebook item IDUse directly for Spark Monitoring API calls — no need to decode pipeline definition
input.workspaceIdWorkspace ID for the notebookUse for cross-workspace notebooks
input.parametersPipeline parameters passed to notebookUseful context for understanding iteration-specific behavior
output.result.sessionIdLivy session UUIDThis is the livyId — use directly with Spark Monitoring APIs
output.result.runIdNotebook/SJD job instance IDCan also query via Job Scheduler API
output.result.runStatusSucceeded / FailedDetermines which diagnostic steps to run
output.result.error{ ename, evalue, traceback[] }Full Python exception with traceback — often sufficient for diagnosis
output.result.highConcurrencyModeStatusnull or HC statusDetect shared session scenarios
output.result.metadata.runStartTimeISO timestampActual Spark execution start
output.result.metadata.runEndTimeISO timestampActual Spark execution end
output.SparkMonitoringURLRelative URL to Fabric Spark MonitorShare with user for visual inspection
output.executionDurationRuntime in secondsQuick duration check
error.messagePipeline-level error messageSummary of failure (may duplicate output.result.error)
error.failureTypeUserError / SystemErrorQuick classification

Extract livyId and resolve Spark application:

# From the queryActivityRuns response, for each Notebook/SJD activity:
livyId="<activity.output.result.sessionId>"
notebookId="<activity.input.notebookId>"
workspaceId="<activity.input.workspaceId>"  # may differ from pipeline workspace

# Get the Spark application ID for this session
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/notebooks/$notebookId/livySessions/$livyId" \
  --query "sparkApplicationId" --output tsv

No time correlation needed — output.sessionId gives the exact Livy session.

Handling null sessionId (Spark never started):

# When output.result.sessionId is null, Spark never launched.
# Check output.result.error for the Python traceback:
#   output.result.error.ename   — exception class name
#   output.result.error.evalue  — exception message
#   output.result.error.traceback — full stack trace lines
# Also check the pipeline-level error:
#   error.errorCode, error.message, error.failureType
# Common causes:
#   - Library/environment setup failure
#   - Invalid Spark pool configuration
#   - Capacity exhausted (could not allocate executors)
#   - Notebook syntax error caught before submission

Business logic exceptions vs Spark infra failures: When error.failureType is UserError and output.result.error.traceback shows a deliberate raise Exception(...) in user code, this is a business logic failure — Spark ran successfully but the notebook intentionally failed. Report this separately from Spark infrastructure issues. No Spark-level diagnostics are needed for these.

Step P4b — Extract Exact Notebook Cell & Line from Traceback

The output.result.error.traceback array from queryActivityRuns is the primary source for identifying exactly which notebook code failed. Parse the traceback lines to extract the cell number, line number, and failing code.

Traceback format — each entry in traceback[] is a string line. Look for the pattern:

Cell In[<cell_number>], line <line_number>

Example traceback lines:

  File "Cell In[14], line 19"  
    raise Exception(f"Expected key '{key}' not found in URL: {url}")
Exception: Expected key 'cluster_id' not found in URL: https://...

Parsing rules:

  1. Cell number — Cell In[14] = notebook cell #14 (1-indexed)

  2. Line number — line 19 = line 19 within that cell

  3. Exception class — output.result.error.ename (e.g., Exception, ValueError, KeyError)

  4. Exception message — output.result.error.evalue — the human-readable error

  5. Full stack — walk traceback[] bottom-to-top to find the root cause frame

Construct the Notebook Snapshot URL so users can open the exact failed run in the Fabric UI:

https://app.powerbi.com/workloads/de-ds/sparkmonitor/{notebookId}/{livyId}?trident=1&experience=power-bi&ctid={tenantId}&tab=related
ComponentSourceExample
Hostapp.powerbi.com (production) or msit.powerbi.com (MSIT)
notebookIdinput.notebookId from queryActivityRuns8e28e1fd-9d6c-4613-928d-0af78770954b
livyIdoutput.result.sessionId from queryActivityRuns0ec839d8-c4d1-42c5-ab9b-8e438430affb
tenantIdaz account show --query tenantId --output tsv72f988bf-86f1-41af-91ab-2d7cd011db47
tabdata (shows cell outputs) or omit for default Spark monitor view

What to report for each failed activity:

#### Activity: <activityName> [iteration <N>/<total>] — FAILED
- **Notebook**: <notebookId> (resolve display name via Items API)
- **Cell**: Cell In[14], line 19
- **Exception**: <ename>: <evalue>
- **Notebook Snapshot**: [Open in Fabric UI](<constructed snapshot URL>)
- **Parameters**: <key pipeline parameters for this iteration>
- **Traceback** (last 5 frames):
  <paste relevant traceback lines>

For ForEach iterations — group by unique error pattern:

  • If 31/36 iterations fail with the same ename + same cell/line, report once with count

  • Show the unique evalue values (or a sample) to reveal iteration-specific differences

  • Example: "31/36 iterations failed at Cell In[14], line 19 with Exception: Expected key 'cluster_id' not found"

Key insight: For user-code failures (business logic, data validation, missing keys), the traceback is the definitive diagnostic — Spark Monitoring APIs will show all jobs SUCCEEDED because the Spark engine ran fine; it was the Python code that raised an exception.

Step P4c — Validate with Spark Monitoring Jobs API

To confirm whether the failure is in Spark infrastructure or user code, check the Spark job-level status:

# Get all Spark jobs for the session
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
  --url "$FABRIC_API_URL/workspaces/$workspaceId/notebooks/$notebookId/livySessions/$livyId/applications/$sparkApplicationId/jobs" \
  --output json

Classification logic:

Spark Jobs Statusoutput.result.errorDiagnosis
All SUCCEEDEDHas traceback with Cell In[N]User-code failure — Python/notebook logic error. Report cell/line from traceback. No Spark-level diagnostics needed.
Some FAILEDHas tracebackSpark infrastructure failure — proceed with full Spark diagnostics (stages, executors, memory). The traceback may show Py4JJavaError wrapping a Spark exception.
All SUCCEEDEDNo error (activity Succeeded)Healthy — check performance only if slow.
Jobs endpoint returns 404AnySession data purged — rely on traceback from queryActivityRuns. See Data TTL note below.

Data TTL: Spark Monitoring data (stages, jobs, executor logs, driver stderr) is retained on the online Spark History Server for a limited time after session completion. For sessions that completed hours or days ago, the monitoring endpoints may return 404. The queryActivityRuns traceback data has a longer retention but also expires (observed: data available for ~1 hour after run, then purged). Always attempt queryActivityRuns first — it is the most reliable data source for recent failures.

Step P5 — Run Standard Diagnostics on Each Session

For each Spark session found (where sessionId is not null and Spark jobs show failures):

  1. Apply Step 2 (auto-route by session state) from the main workflow

  2. Run Steps 3–6 as applicable (failure analysis, performance, resource, session health)

  3. Tag findings with the activity name (+ iteration index if ForEach) for the report

Skip full Spark diagnostics when Step P4c confirms all Spark jobs SUCCEEDED — the traceback from Step P4b is sufficient.

Handle Nested Pipelines (ExecutePipeline activities)

For each ExecutePipeline activity:

# Extract child pipeline run info from activity output
childJobInstanceId="<from activity output>"

# Recurse: run the full Pipeline Run Diagnosis (Steps P1–P6) on the child pipeline
# Use the child pipeline's workspaceId and pipelineId from typeProperties

Report nested pipeline findings under a sub-section: "Child Pipeline: <name> (run <id>)".

Step P6 — Pipeline-Level Report

Present a combined report showing all activities and their Spark diagnostics:

## Pipeline Diagnostic Summary

**Pipeline**: <pipeline name> | **Run ID**: <jobInstanceId> | **Status**: <status>
**Duration**: <startTimeUtc> → <endTimeUtc>

### Activity Overview

| # | Activity | Type | Status | Duration | Spark Issues | Notes |
|---|----------|------|--------|----------|--------------|-------|
| 1 | LoadRawData | TridentNotebook | Failed | 5m 23s | 1 HIGH, 1 MEDIUM | |
| 2 | LoadRawData [iter 2] | TridentNotebook | Succeeded | 4m 10s | 0 HIGH, 1 MEDIUM | ForEach iteration 2 |
| 3 | TransformSilver | TridentNotebook | Succeeded | 12m 45s | 0 HIGH, 2 MEDIUM | Retried 1× |
| 4 | PublishGold | SparkJob | Cancelled | — | — | Upstream failure |
| 5 | RunChildPipeline | ExecutePipeline | Failed | 8m 30s | See child report | Nested pipeline |
| 6 | SetupEnv | TridentNotebook | Failed | 0s | — | Spark never started (library error) |

### Detailed Findings

#### Activity: LoadRawData (Failed)
| # | Severity | Finding | Fix |
|---|----------|---------|-----|
| 1 | HIGH | Executor OOM in stage 4 (skewed partition) | Enable AQE skew join |
| 2 | MEDIUM | Disk spill 1.3 GB in stage 3 | Increase shuffle partitions to 400 |

#### Activity: TransformSilver (Succeeded — performance issues)
| # | Severity | Finding | Fix |
|---|----------|---------|-----|
| 1 | MEDIUM | Data skew ratio 4.1× in stage 7 | Salt the join key |
| 2 | MEDIUM | Core efficiency 28% | Reduce executor count |

#### Activity: SetupEnv (Failed — no Spark session)
**Error**: library packaging error — `pip install failed for package xyz==2.0`
**Fix**: Verify package version compatibility with Fabric runtime Python version.

#### Activity: ValidateData [31/36 iterations FAILED — user-code error]
**Notebook**: Check load_ virtualization (8e28e1fd-...)
**Cell**: Cell In[14], line 19
**Exception**: `Exception: Expected key 'cluster_id' not found in URL`
**Spark Jobs**: 13/13 SUCCEEDED — failure is in Python code, not Spark infrastructure
**Pattern**: 31 iterations fail at the same cell with the same exception class; 5 succeed
**Sample failing parameters**: `cluster_url=https://...`, `batch_key=...`
**Root Cause**: Notebook business logic expects a key in the URL that is missing for certain cluster URLs
**Fix**: Update notebook validation logic to handle URLs without the expected key, or fix upstream data

#### Child Pipeline: IngestPipeline (Failed)
[Recursive report from child pipeline diagnosis]

Prioritization: In the report, order activities by: (1) Failed activities first, (2) Succeeded but slow, (3) Succeeded and healthy. For ForEach iterations, group by activity name and highlight which iterations failed.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills-for-fabric · skills/spark-cli · commit f8fac11
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/skills-for-fabric

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download spark-cli.zip