Skip to content

Use the libyaml FullLoader when libyaml is available - #70943

Open
rjgoyln wants to merge 1 commit into
apache:mainfrom
rjgoyln:fix-cfullloader-never-used
Open

Use the libyaml FullLoader when libyaml is available#70943
rjgoyln wants to merge 1 commit into
apache:mainfrom
rjgoyln:fix-cfullloader-never-used

Conversation

@rjgoyln

@rjgoyln rjgoyln commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

Summary

These YAML helpers promise the libyaml C implementation whenever it is available. safe_load and dump deliver it; FullLoader never has — the __getattr__ branch that looks up CFullLoader discards the result and falls through to the pure-Python loader, so the fast path has always been dead code.

Change

The module exists in three copies — airflow.utils, airflow.sdk, airflowctl.ctl.utils — all carrying the same defect, and all three are fixed here. Unifying them is out of scope and already tracked by a TODO in the airflow-ctl copy.

Tests

One test per copy, each failing without its fix. CFullLoader is injected rather than assumed, so the assertion holds whether or not the machine running the tests has libyaml compiled in.

Behavior change

No in-tree caller reads FullLoader through these wrappers, so nothing in Airflow changes. External callers now receive CFullLoader, which does not see constructors registered via yaml.add_constructor(tag, fn).


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

The YAML helper modules promise that YAML operations use the faster C
implementation whenever libyaml is installed. For FullLoader that promise
was never kept: the branch that looked up CFullLoader discarded its result,
so callers always received the pure-Python loader.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant