namanjain24-sudo commented on issue #73739: URL: https://github.com/apache/airflow/issues/73739#issuecomment-5840338638
Confirmed on main (not just 3.3.1). To trace the exact path: `find_dag_file_paths` (`utils/file.py`) treats a `.zip` as a single Dag-processing unit — when `zipfile.is_zipfile(path)`, it appends the zip's own path to the file list rather than iterating its members. So `DagFileParseRequest.file` for a zipped Dag is the `.zip` file's real path, and in `check_dag_file_stability` (`dag_version_inflation_checker.py`), `Path(file_path).read_bytes()` successfully reads the zip's raw binary bytes, then `ast.parse(...)` raises `SyntaxError` on that binary content (confirmed empirically: `source code string cannot contain null bytes`) — caught by the same broad `except (SyntaxError, ValueError, TypeError, FileNotFoundError)`, so the check silently returns an empty result. `BundleDagBag` parses the Dags inside just fine, since it goes through the zip's own import machinery separately — only this stability check is blind to zip-packaged Dags. A fix would need `check_dag_file_stability` (or its caller in `processor.py::_parse_file`) to detect the zip case and iterate the archive's members (`zipfile.ZipFile(file_path).infolist()`, filtered the way `might_contain_dag` already filters elsewhere) and run the AST check per inner `.py` member instead of on the archive's own bytes. --- Drafted-by: Claude Code (Sonnet 5); reviewed by @namanjain24-sudo before posting -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
