I’m unable to get my Audio Course certificate because the progress-checking Space is showing a 404 Runtime Error.
Could you please check and resolve this issue?
This looks like a known issue:
The progress-checking Space appears to be failing server-side before it can actually evaluate your username, and there is already an open upstream issue (#247) tracking essentially this failure path.
So for this particular error, things like clearing the browser cache, changing browsers, or re-uploading your model are unlikely to help.
The immediate failure is in the public Check My Progress - Audio Course Space. Its current source tries to read the Unit 7 pass roster from huggingface-course/audio-course-u7-hands-on/usernames.csv. That access currently fails, and because the Unit 7 check is not isolated from the rest of the startup path, the exception brings down the whole progress checker.
One small but important qualification: I would describe this as “the Space can no longer access the Unit 7 roster”, rather than assuming that the dataset was definitely deleted. Hugging Face’s RepositoryNotFoundError documentation says the same error can also occur when a repository is private and the current credentials do not have access. From outside the maintainer account, those cases are difficult to distinguish.
The good news is that the official Audio Course certification rules still say:
- 3 of 4 hands-on assignments → Certificate of Completion
- 4 of 4 → Certificate of Excellence
So if you already know that you satisfy three assignments, it is worth trying the official Audio Course Certification Space directly. The public progress checker is useful for self-evaluation, but the certification page performs its own checks.
If that certification Space also returns an error, that likely needs maintainer-side attention as well: there are already recent reports from users claiming 3/4 completion and 4/4 completion who were unable to generate a certificate.
A robust fix would probably separate two things:
- restore/fix access to the Unit 7 roster, and
- make failure of that one roster non-fatal, so Units 4–6 can still be checked and Unit 7 can simply be shown as temporarily unavailable.
That second change would help even if the underlying cause turns out to be a token/permission change rather than a deleted repository.
What seems established, and what is still uncertain
What seems fairly well established
The current public progress checker has this dependency:
Check-my-progress-Audio-Course
→ Unit 7 evaluation
→ huggingface-course/audio-course-u7-hands-on/usernames.csv
The existing GitHub issue identifies the same path.
There is another implementation detail that makes the impact larger than necessary: the progress calculation is also invoked while the Gradio UI is being constructed. As a result, failure of the Unit 7 dependency is not just reported as something like:
Unit 7: temporarily unavailable
Instead, it prevents the entire Space from starting.
This also explains why the error can occur before your own username or model state becomes relevant.
What is not established from the public error
The observed RepositoryNotFoundError does not uniquely identify the underlying administrative cause.
Possibilities include:
- the roster repository no longer existing;
- its visibility having changed;
- the Space’s token no longer having permission;
- organization/repository permissions having changed;
- the credential used by the Space having been rotated or removed.
The Hugging Face Hub deliberately does not make a private repository visible to unauthorized clients, so “not found” and “not allowed to see it” can look very similar from outside. The relevant behavior is documented in the Hub error documentation.
For that reason, the fastest definitive test is something only the maintainer can perform: attempt to read the roster using the same credential used by the official Space.
A low-cost maintainer-side check
If someone maintaining the Course/Spaces looks at this, I think the shortest diagnostic path is:
-
From the official progress-checking Space environment, test whether its current
HF_TOKENcan read:huggingface-course/audio-course-u7-hands-on/usernames.csv -
If it cannot:
- check whether the dataset still exists under that repo ID;
- check visibility/ownership;
- check whether the Space token still has the required read permission.
The current Hugging Face guidance for application credentials is in the User Access Tokens documentation.
-
Independently guard the Unit 7 lookup so its failure does not prevent Units 4–6 from being evaluated.
-
Avoid running the full certification lookup merely to construct the initial Gradio component; defer the remote checks until the user actually requests them.
That gives two independent protections:
repair the dependency
and
prevent that dependency from becoming a single point of failure
The latter is useful even after the immediate incident is fixed.
Since a Certificate of Completion officially needs only 3/4 assignments, graceful degradation also has a practical benefit: a temporarily unavailable Unit 7 registry should not necessarily make the entire 3/4 self-evaluation path unusable.
The official certificate generator is a separate path
There is one more distinction that may matter here.
The public progress checker and the actual certificate generator are not the same application.
The certificate generator source calls a separate private Space:
MariaK/Check-Audio-Course-Progress
and, after a successful result, records certified users in another private dataset.
So the flow is closer to:
public self-evaluation Space
→ useful for checking progress
while separately:
official certificate Space
→ private progress checker
→ certificate generation / certified-user record
That means repairing the public self-evaluation Space may not automatically repair every possible certificate-generation failure.
Conversely, if the private certification path is still healthy, somebody who already satisfies the requirements may not actually need the public self-evaluation Space before requesting the certificate.
Recent discussion #16 and discussion #17 suggest that at least some users are also seeing errors in the certificate generator, but its internal progress checker is private, so I would not assume that those errors have exactly the same root cause without a maintainer checking it.
A temporary self-check, and a separate Unit 7 problem
The GitHub issue also links to a community-patched progress checker. That may be useful as a temporary sanity check for course progress while the official checker is unavailable.
I would not treat a community fork as a replacement for the official certificate generator, though: generating/recording the official certificate goes through the separate private certification path described above.
There is also currently another failure visible on the official Unit 7 assessment Space: its present traceback ends in No space left on device while loading facebook/mms-lid-126.
I would keep that separate from the progress-checker’s roster-access failure for now. They affect related Course infrastructure, but the currently observable errors are different, so assuming one common root cause could make debugging harder.
So the shortest version is: your screenshot is consistent with an existing Course-side infrastructure problem rather than something you can fix locally. The most useful tracking point is audio-transformers-course issue #247, and if you already satisfy 3/4 assignments, trying the official certification Space directly is the lowest-cost next step. If that also errors, the remaining path appears to require maintainer-side inspection of the private certification/checking infrastructure.