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 |
What appears to be failing
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 loader.
Validation
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:
- loaded all 20 questions successfully;
- downloaded and mapped all 5 referenced attachments;
- returned HTTP 200 from
/files/{task_id} for:
- one PNG;
- two MP3 files;
- one Python file;
- one XLSX file.
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.
The two practical options
If you can wait
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.
If you need to continue now
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.
Immediate workaround: create a private scoring-Space duplicate
-
Open the official agents-course/Unit4_scoring Space.
-
Duplicate it into your own account.
-
Keep the duplicate private.
A protected Space is not equivalent for this use case: the source may be restricted, but the running application can still be publicly reachable. The file-serving application itself needs to remain private.
-
Make sure your HF account has accepted the access conditions for the GAIA dataset.
GAIA access is granted per user, so the account owning the token must have access.
-
Create a read token and add it to the duplicate Space under:
Settings → Variables and secrets → Secrets
Use the name:
HF_TOKEN
Secrets from the original Space are not copied into a duplicate, so this must be added manually.
-
Apply the change shown in PR #2.
The essential behavior is:
if file_path is repository-relative:
download it from gaia-benchmark/GAIA
use the returned local cache path
else:
keep the existing local-path behavior
-
Rebuild the Space.
-
Check the startup log.
The useful sanity check is:
Found 20 questions matching the criteria
Stored file path mappings for 5 tasks
-
Test one or more attachment routes.
For example, the XLSX task should return HTTP 200 from:
/files/7bd855d8-463d-4ed5-93ca-5fe35145f733
Calling the private duplicate
Because the duplicate is private, the agent or script calling it must authenticate with a token that can read that Space.
Store that token as a Secret in the calling environment and send it as a Bearer token. Do not place it in repository files, browser-side JavaScript, logs, or the Space README.
The same read token may be usable for both the private Space and GAIA when it belongs to an account with access to both, although keeping secrets narrowly scoped is preferable where practical.
Alternative workaround: resolve the attachment inside the agent
If authenticating every request to a private scoring-Space duplicate is inconvenient, the same attachment-resolution step can instead be placed inside the agent itself.
A reasonable split is:
/questions → official scoring Space
attachment → authenticated hf_hub_download() from GAIA
/submit → official scoring Space
In that design:
- Use the official
/questions response as the source of truth for the 20 task IDs.
- Match those task IDs to the corresponding GAIA validation rows.
- Use the row’s actual
file_path.
- Download the attachment with
hf_hub_download().
- Pass the resulting local path to the agent’s file-processing tools.
- Keep the file in the runtime cache; do not publish or mirror it.
- Submit only the generated answers through the official
/submit route.
Do not replace the official question set with the first 20 GAIA validation rows. The course selection is a filtered set, and a locally selected first-20 subset may not match the task IDs accepted by the scoring endpoint.
This is still an unofficial workaround, but it avoids exposing a new file-serving endpoint.
Why /questions can work while /files fails
The question endpoint and the attachment endpoint depend on different layers.
/questions only needs metadata such as:
task_id;- question text;
- level;
file_name.
The presence of a file_name in metadata does not mean that the corresponding binary file already exists on the Space filesystem.
The attachment flow additionally requires:
metadata file_path
↓
dataset-repository file
↓
authenticated download
↓
local cache path
↓
task_id mapping
↓
FileResponse
The current failure occurs in that metadata-to-local-file transition. This is why /questions can return the correct XLSX filename while /files/{task_id} still returns a mapping-related 404.
The Hugging Face Hub download API is already designed for this transition: hf_hub_download() retrieves one repository file, stores it in the Hub cache, and returns its local path.
Scope and limitations
A few distinctions are worth keeping clear:
- I am not an HF maintainer, and this is not an official confirmation.
- The PR being shown as “ready to merge” means that it is technically mergeable; it does not mean that it has been reviewed or approved.
- The end-to-end validation was performed on a private duplicate of the current Space, not on the official production Space.
- The official Space’s token and deployment configuration are not visible externally, so the maintainers still need to verify that configuration when merging.
- Until the change is merged and the official Space is rebuilt, the public endpoint should still be treated as unfixed.
- The PR deliberately does not include unrelated cleanup such as dependency pinning, loader refactoring, revision management, or broader error-response changes.
Those may be useful follow-up improvements, but they are not required to restore the attachment endpoint.
Useful references:
