[BUG] live_pool schedule time values corrupted during Environment deployment (PyYAML sexagesimal parsing)

[alwortma2]

Library Version

1.2.0

Python Version

3.11.15

Operating System

Windows

Authentication Method

Service principal (secret)

What is the problem?

When deploying an Environment item that has a  live_pool  schedule configured in  Setting/Sparkcompute.yml , the start_time  and  end_time  fields are silently corrupted before being sent to the Fabric API, causing the publish to fail with:

Error Code: UpdateArtifactFailure. Error Message: Succeeded = False, ErrorInfo =
(Code = SparkSettingsInvalidClpSchedule, Message = 'Invalid custom live pool schedule EndTime: 64800.00:00:00.')

The cause is that  _process_environment_file  in  _items/_environment.py  performs a  yaml.safe_load  →  yaml.dump  round-trip on  Sparkcompute.yml  whenever  instance_pool_id  is present. PyYAML implements YAML 1.1, which parses unquoted  HH:MM:SS  values as base-60 (sexagesimal) integers:

start_time: 08:00:00 → yaml.safe_load → 28800 (int) → yaml.dump → 28800
end_time: 18:00:00 → yaml.safe_load → 64800 (int) → yaml.dump → 64800

The Fabric API receives the bare integer  64800  and interprets it as a .NET  TimeSpan  of  64800.00:00:00  (64800 days ≈ 177 years), which fails validation. This affects any Environment item with a  live_pool  schedule, regardless of whether any  spark_pool  parameter replacement is actually needed — the round-trip runs unconditionally whenever  instance_pool_id  appears in the file.

Steps to reproduce

1. Create an Environment item with a  live_pool  schedule in  Setting/Sparkcompute.yml :

instance_pool_id:
live_pool:
state: Enabled
schedule_state: Enabled
schedule:
recurrence_type: Daily
start_time: 08:00:00
end_time: 18:00:00
time_zone: Pacific Standard Time

2. Deploy the Environment item using fabric-cicd
3. Observe the  SparkSettingsInvalidClpSchedule  error during the Environment publish step

Expected behavior

The  start_time  and  end_time  values are preserved as time strings ( 08:00:00 ,  18:00:00 ) and accepted by the Fabric API.

Actual behavior

PyYAML parses  18:00:00  as the integer  64800  (18×3600).  yaml.dump  outputs  64800 . The Fabric API rejects this as  64800.00:00:00  — an invalid .NET TimeSpan.

Is there an ideal solution?

Replace  yaml.safe_load  /  yaml.dump  with  ruamel.yaml  (YAML 1.2), which does not perform sexagesimal parsing and preserves the original string representation of time values through the round-trip. Alternatively, the  yaml.dump  call could use a custom representer that re-quotes values that were originally strings.

Additional context, screenshots, logs, error output, etc

Workaround (until fixed): quote the time values in  Sparkcompute.yml  so PyYAML treats them as strings:

# Broken — PyYAML YAML 1.1 parses as integer
start_time: 08:00:00
end_time: 18:00:00

# Fixed — single quotes force string type through round-trip
start_time: '08:00:00'
end_time: '18:00:00'

Note this workaround must be applied manually to the committed file and will be overwritten if the file is re-exported from the Fabric portal, since the portal writes unquoted time values.

[microsoft-github-policy-service]

Thank you for submitting this issue, Alex Wortman (@alwortma2).
A member of the Fabric CICD team will review your submission and provide feedback shortly.

[github-actions]

AI Assessment: Potential Bug

The described behavior is plausible and aligns with known issues in PyYAML's YAML 1.1 handling—unquoted "HH:MM:SS" values are parsed as sexagesimal integers, thus corrupting time representations in Sparkcompute.yml. Since the library round-trips the content through yaml.safe_load / yaml.dump, this results in the incorrect integer being sent to the Fabric API, leading to validation errors and failed deployments. This is an interoperability bug affecting any Environment item with a live_pool schedule, irrespective of whether parameter replacement is performed, due to the unconditional round-trip whenever instance_pool_id is present.

The severity is elevated: deployment of Environment items fails unless users manually quote time values, which introduces friction and makes the library incompatible with unquoted output from the Fabric portal. This could disrupt CI/CD pipelines and cause unnecessary failures.

Your suggested solution of using ruamel.yaml (YAML 1.2) or a custom representer to preserve string types is technically sound and would address the root cause. Documentation should also be updated to warn users about quoting requirements if PyYAML is retained.

Next Steps
🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cicd to notify the team.

[github-actions]

🔔 @microsoft/fabric-cicd — This issue has been flagged by AI triage as requiring team attention. Please review the assessment above.

[shirasassoon]

Alex Wortman (@alwortma2) Thanks for raising this. We are looking into introducing a fix for this issue.

[shirasassoon]

Alex Wortman (@alwortma2) We've determined that a viable workaround is available today, so we won't be making any fixes in the library for this issue.