apache / apache/airflow

Additional cron expression validation

Open
#16,731 3 comments 0 reactions 0 assignees View on GitHub
area:core kind:feature
Dominant language
Python
Stars
46.9k
Forks
17.8k
Avg merge
2d 10h
Merged PRs (30d)
483

Description

**Description**
Airflow should outline (in documentation) what cron expressions are supported, and perform appropriate additional validation on user-supplied cron expressions.

**Use case / motivation**
#16692 proposed displaying a short description about the cron expression in the web UI. This bring out the issue that currently the cron expression formats supported by Airflow are essentially defined by croniter implementation, which is non-standard (POSIX only allows five-segment formats) and sometimes buggy (see https://github.com/apache/airflow/issues/16107#issuecomment-869559200). Since croniter itself does not offer expression description, we need to do this with another tool, meaning that non-standard expressions can be incorrectly described and cause user confusion.

It would be beneficial for Airflow to explicitly specify what cron expression formats are supported (only POSIX, or POSIX plus extensions like the optional year segment, or something else), and perform additional validation to ensure croniter does not receive formats not supported by Airflow, even if it can handle them. Personally I’m inclined to only do POSIX and reject the sixth segment entirely, at least until croniter fixes its handling to correctly interpret it (see taichino/croniter#76).

**Are you willing to submit a PR?**
Yeah

**Related Issues**
https://github.com/apache/airflow/issues/16107#issuecomment-869559200
#16692
taichino/croniter#76

Contributor guide

Open the contributing guide

Research direction

Start by reviewing croniter's supported expression formats and the linked discussions, especially issue 16107 and croniter#76. Decide which formats Airflow will support, document that contract, and ensure unsupported user-supplied expressions are rejected before croniter processes them. Done means the documentation and validation agree and the related UI description cannot misinterpret accepted expressions.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, documentation
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.