[FEATURE] Remove scheduled job

[aviatco]

Use Case / Problem

Enables users to remove a specific scheduled job related to an item via CLI.
Currently this is not supported.

Proposed Solution

Job Run Remove Command Design

Overview

The job run-rm command deletes a scheduled job from a Fabric item. This complements the existing schedule management commands (run-sch, run-update) and follows the CLI's rm convention for deletions.

Command Syntax

fab job run-rm <path> --id <scheduled-id> [--force]

Parameters

• <path>: Required. The path to the item containing the scheduled job
• --id: Required. The ID of the scheduled job to remove
• --force: Optional. Skip confirmation prompt before removing the job

Supported Item Types

• .Notebook
• .DataPipeline
• .SparkJobDefinition
• .Lakehouse

---

API Endpoint

DELETE /v1/workspaces/{workspaceId}/items/{itemId}/jobs/{jobType}/schedules/{scheduleId}

Link to API: https://learn.microsoft.com/en-us/rest/api/fabric/core/job-scheduler/delete-item-schedule?tabs=HTTP

---

User Experience

Default Behavior (With Confirmation)

$ fab job run-rm pipeline1.DataPipeline --id abc-123

⚠ You are about to delete schedule 'abc-123' from 'pipeline1.DataPipeline'
  This action cannot be undone.

? Are you sure? (y/N) y

* Schedule 'abc-123' deleted from 'pipeline1.DataPipeline'

Force Mode (Skip Confirmation)

$ fab job run-rm pipeline1.DataPipeline --id abc-123 --force

* Schedule 'abc-123' deleted from 'pipeline1.DataPipeline'

Design Decisions

Command Naming: job run-rm

• Follows the run-* prefix pattern for schedule operations
• Consistent with CLI's acl rm command
• Matches Unix conventions users expect

Parameter Naming: --id

• Context (deleting schedules) makes meaning clear
• Consistent with job run-update --id which also operates on schedules
• Brief and unambiguous in this context

Safety: Confirmation Required

• Default behavior requires user confirmation before deletion
• Prevents accidental deletion of configured automation
• --force flag available for scripting/automation

No Cascading: Running Instances Unaffected

• Deleting a schedule does NOT cancel already-running instances
• Users must use job run-cancel separately to stop running jobs

---

User Messages

Using fab_ui:

# Info Messages
utils_ui.print_grey(f"Removing scheduled job with ID '{scheduled_id}' from '{path}'...")

# Success Messages
utils_ui.print_output_format("Job schedule removed successfully")

# Error Messages
utils_ui.print_error_format(f"Job schedule removal failed: {error_message}")

Command Support Configuration

Add the new subcommand in command_support.yaml

job:
  supported_items:
    - spark_job_definition
    - notebook
    - data_pipeline
    - lakehouse
  subcommands:
    # ... existing subcommands ...
    run_rm:  # Add the new subcommand here

Usage Examples

Basic Usage

# Delete a schedule (with confirmation)
fab job run-rm notebook1.Notebook --id schedule-abc-123

# Delete schedule in nested folder
fab job run-rm /ws1.Workspace/reports.Folder/daily.DataPipeline --id schedule-xyz-789

Automation & Scripting

# Skip confirmation in scripts
fab job run-rm pipeline1.DataPipeline --id old-schedule --force

Typical Workflow

# 1. List schedules to find the ID
fab job run-list pipeline1.DataPipeline --schedule

# 2. Check schedule details before deletion
fab job run-status pipeline1.DataPipeline --id abc-123 --schedule

# 3. Delete the schedule
fab job run-rm pipeline1.DataPipeline --id abc-123

Related Commands

Command	Purpose	Relationship
job run-sch	Create new schedule	Opposite operation
job run-update	Modify existing schedule	Alternative to delete+recreate
job run-list --schedule	List all schedules	Discover schedule IDs
job run-status --schedule	View schedule details	Verify before deletion
job run-cancel	Cancel running instance	Different domain (instances ≠ schedules)

---

Testing Strategy

• Test successful deletion with VCR.py recordings
• Test 404 error (schedule not found)
• Test force flag behavior (confirmation bypass)
• Test invalid paths and malformed IDs
• Skip 403 permission tests (cannot mock in VCR)

---

Success Criteria

• ✅ Users can delete schedules with clear confirmation flow
• ✅ --force flag works for automation scenarios
• ✅ Error messages clearly distinguish between "not found" and permission issues
• ✅ Command follows established CLI patterns
• ✅ Supports --output json for scripting
• ✅ Help text and examples are clear and complete

Alternatives Considered

No response

Impact Assessment

• This would help me personally
• This would help my team/organization
• This would help the broader fabric-cli community
• This aligns with Microsoft Fabric roadmap items

Implementation Attestation

• I understand this feature should maintain backward compatibility with existing commands
• I confirm this feature request does not introduce performance regressions for existing workflows
• I acknowledge that new features must follow fabric-cli's established patterns and conventions

Implementation Notes

No response

[ayeshurun]

/triaged

[ayeshurun]

/help-wanted

[microsoft-github-policy-service]

This issue has been marked as help wanted.
Community contributions are welcome and appreciated.

[CSharplie]

Hi @ayeshurun

I'm not sure about the job_type parameter. In fact, "ITJobMap" is used to define the job type by mapping it to the object type. This mechanism is already used by existing job commands which do not have this parameter.

class FabricJobType(Enum):
    SPARK_JOB = "sparkjob"
    RUN_NOTEBOOK = "RunNotebook"
    PIPELINE = "Pipeline"
    TABLE_MAINTENANCE = "TableMaintenance"


ITJobMap: dict[ItemType, FabricJobType] = {
    # {"commandLineArguments": "--param1 TEST --param2 1234"}
    ItemType.SPARK_JOB_DEFINITION: FabricJobType.SPARK_JOB,
    # { "parameters": {"param1": {"value": "FullPipeline", "type": "string"}, "param2": { "value": 2, "type": "int" } }}
    ItemType.NOTEBOOK: FabricJobType.RUN_NOTEBOOK,
    # {"parameters": { "param1": "FullPipeline", "param2": 2 }}
    ItemType.DATA_PIPELINE: FabricJobType.PIPELINE,
    # {"tableName": "orders", "optimizeSettings": {"vOrder": true, "zOrderBy": ["account_id"]}, "vacuumSettings": {"retentionPeriod": "7.01:00:00"}}
    ItemType.LAKEHOUSE: FabricJobType.TABLE_MAINTENANCE,
}

Passing the job type as a parameter could cause a misalignment with the object type by allowing a different one to be forced.

[aviatco]

@CSharplie Thank you for bringing this up.
You are correct, the job_type parameter is determined by the item type within the code and should not be passed as a command parameter.
The design has been updated accordingly.