Spaces:

---

huggingface-projects

/

Deep-RL-Course-Certification

Like 76

Running

For an issue observed in this thread: /static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Ferror-generating-deep-rl-course-certificate%2F177241%3C%2Fa%3E%3C%2Fp%3E

Summary

This PR makes the Deep RL Course Certification Space easier to rebuild and improves the error message around the certificate writeback step.

Changes:

• Pin Python to 3.10 because a fresh build currently uses Python 3.13 and Pillow == 9.4.0 fails to build there.
• Pin huggingface_hub<1 as a temporary compatibility fix because the Space imports the legacy Repository class.
• Add input validation for empty username / name fields to avoid accidentally scanning all matching public Hub models.
• Replace the generic Gradio failure around the certified-users writeback step with a clearer message and a logged exception.

This PR intentionally does not return a certificate when the writeback step fails, because certified_users.csv may be intended as the official issuance record. It only makes the failure explicit instead of surfacing a generic Error.

Investigation notes

I duplicated the Space and tested the current code path with the affected username szymon-hyziak.

Observed:

• With Python 3.10, huggingface_hub<1, and a valid HF_TOKEN, the UI starts.
• The app finds the user's models, downloads/parses the model card metadata, and computes pass_percentage ~= 81.8, which should qualify for a completion certificate.
• If the certified-users writeback step is bypassed, the certificate image and progress table render correctly.
• In my duplicate, the remaining failure is the final push to huggingface-projects/Deep-RL-Course-Certification, which my token understandably cannot write to.

Maintainer-side follow-up required

This PR cannot update or verify the official Space secret.

Please check:

• whether the official Space HF_TOKEN secret is still valid;
• whether the token owner still has write access to huggingface-projects/Deep-RL-Course-Certification;
• whether the official Space logs show a failure around repo.push_to_hub(...);
• whether the Space should be restarted/rebuilt after updating the secret.

I cannot prove the official Space fails at exactly the same line because I do not have access to the official Space logs or maintainer token, but the duplicated Space strongly points to the certificate writeback path rather than the user's progress/model metadata.