[Manohar Paturi (ManoharPaturi)]

Motivation & Context

_load_gaia_local prefers parquet files (the comment calls it the new format, validation split first) but GAIA._ensure_data only treated a data dir as ready when it contained metadata.jsonl. Pointing data_dir at a parquet-only mirror was ignored and the runner demanded HF_TOKEN for a fresh download even though the local data was fully usable. Issue #9337 has the repro.

This PR replaces #9340, which was closed while it still had outstanding review feedback: _ensure_data() still returned successfully whenever any metadata.jsonl existed, without checking incomplete parquet shards in the same directory. Per the close reason, it is being resubmitted here with that feedback addressed on top of the original fix.

Description & Review Guide

• What are the major changes? _ensure_data now accepts a data dir through _has_usable_local_data(): if any metadata*.parquet file is present (the same glob the loader itself reads), the parquet snapshot must be complete; otherwise the dir is usable when metadata.jsonl is present. A JSONL-only layout keeps working exactly as before.
• What is the impact of these changes? Parquet-only data dirs run offline, and a mixed layout (metadata.jsonl beside an incomplete metadata-XXXXX-of-NNNNN.parquet family) no longer silently passes. The loader reads parquet first and only falls back to JSONL when no parquet file is present, so such a mixed dir would have loaded a truncated task set without any error — this is the review feedback from Python: fix(lab-gaia): accept local parquet data in _ensure_data #9340, addressed by requiring a complete parquet snapshot whenever any metadata parquet file is present.
• What do you want reviewers to focus on? The _has_usable_local_data helper in gaia.py, plus the two new regression tests: test_jsonl_does_not_rescue_an_incomplete_parquet_family (mixed layout with shard 0 of 2 forces download; completing the family makes the dir ready again) and test_jsonl_only_layout_is_still_accepted.

The full GAIA suite (9 tests), Ruff (pinned 0.16.10) check/format, pyright, and mypy are clean locally.

Related Issue

Fixes #9337

AI Assistance

• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change.

[Manohar Paturi (ManoharPaturi)]

The Public API Compatibility check fails on every open PR in this repo right now (e.g. #9602, #9607, and all of this author's open PRs), so it looks like a repo-wide CI issue rather than something introduced by this change.

The job crashes inside griffe while loading the base (main) snapshot, before it compares the PR changes — the traceback points at the base copy of the package:

griffe._internal.exceptions.AliasResolutionError: Could not resolve alias
agent_framework._workflows._edge.EdgeGroup.builtin_type pointing at builtins.type
(in /tmp/python-api-base-.../python/packages/core/agent_framework/_workflows/_edge.py:315)

Example run: https://github.com/microsoft/agent-framework/actions/runs/39810016173/job/119933441343

None of the changes in this PR touch _workflows/_edge.py. Filed an issue for the CI failure; happy to help debug if useful.