Ah… I only just realized that there was no PR open for this, so I opened one. If you need to unblock yourself immediately, the quickest route is probably to duplicate the scoring Space and apply the same fix. Otherwise, the next option is to wait for HF to review and merge the PR:
I still do not see a public confirmation or ETA from an HF maintainer. At the time of writing, the public Unit4_scoring
Space still uses the old attachment-path logic, so the official /files/{task_id}
endpoint remains affected.
However, there is now a minimal Space PR: Fix GAIA attachment downloads. The same failure is also tracked in agents-course issue #624 and issue #647.
| Item | Current status |
|---|---|
| HF maintainer confirmation / ETA | I have not seen one publicly |
| Fix PR | Open; currently shown as ready to merge |
| Official scoring Space | Fix not yet applied |
| Private duplicate with the patch | Tested successfully |
| Referenced attachments | 5/5 returned HTTP 200 |
The current GAIA dataset documentation describes attachment file_path
values as paths relative to the dataset repository root, for example:
2023/validation/<task-id>.xlsx
The current public Unit4_scoring/main.py, however, checks those values directly with
os.path.exists()
as though the files had already been materialized on the Space filesystem.The resulting flow is approximately:
GAIA returns a repository-relative file_path
↓
the scoring Space checks it as an existing local path
↓
os.path.exists() returns false
↓
no task_id → local file mapping is stored
↓
/files/{task_id} returns:
"No file path associated with task_id ..."
This appears to be the failure point in the current public code.
The PR keeps the existing behavior for absolute local paths, but resolves repository-relative paths with hf_hub_download()
. That downloads the attachment into the normal Hugging Face cache and gives the existing file-serving route a real local path.
The change is intentionally narrow: it does not restructure the API, question selection, submission logic, or dataset .
I tested the change end to end on a private duplicate of the current scoring Space, using the current runtime and a read token with GAIA access.
The duplicate:
/files/{task_id}
for: Before the patch, the startup log reported:
Stored file path mappings for 0 tasks.
After the patch:
Stored file path mappings for 5 tasks.
I also checked the returned filenames, byte counts, and basic file signatures, so this was not only a successful startup or metadata-only test.
Follow the Space PR and the existing #624 / #647 reports.
Once the PR is merged and the official Space is rebuilt, the public /files/{task_id}
endpoint can be checked again.
Duplicate the scoring Space privately and apply the same change from the PR.
Important: this private scoring-Space duplicate is separate from your actual Agent / Final Assignment Space. Your assignment Space can remain public for the normal course workflow; only the temporary scoring duplicate should be private.
The scoring duplicate uses its owner’s token to retrieve files from the gated GAIA dataset. If its /files/{task_id}
endpoint were made public, it could unintentionally expose gated validation attachments outside the normal GAIA access flow.
Useful references:
Unit4_scoring
HF_TOKEN
environment variable