Fix race condition on GitHub authors

[glenn-jocher]

🛠️ PR Summary

_{Made with ❤️ by Ultralytics Actions}

🌟 Summary

🚀 Improves MkDocs postprocessing stability and performance by pre-resolving GitHub authors once (avoiding parallel cache write conflicts) and bumping the plugin version to 0.2.4.

📊 Key Changes

• 🏷️ Version bump: __version__ updated from 0.2.3 → 0.2.4.
• 🧠 Pre-resolve authors in the main process: postprocess_site() now calls resolve_all_authors() before spawning worker processes, preventing race conditions when writing the authors cache file.
• 🔄 Refactor git author lookup flow:
  • process_html() and get_git_info() no longer resolve authors on-demand per file.
  • get_git_info() now expects authors to already be present in git_data (precomputed).
• 💾 New cache helpers + safer network behavior:
  • Added load_author_cache() / save_author_cache() utilities for mkdocs_github_authors.yaml.
  • Introduced request timeouts (TIMEOUT = 10) and lazy default avatar resolution (get_default_avatar()), reducing risk of hangs and repeated network calls.
• 🧹 Cleanup/removal: Removed thread-lock based caching logic and the older per-file author resolution path, simplifying concurrency behavior.

🎯 Purpose & Impact

• ✅ More reliable builds in parallel mode: Avoids worker processes competing to update the same YAML cache file, which could previously cause flaky builds or corrupted cache writes 🛠️.
• ⚡ Faster documentation builds: Resolving all unique emails once reduces repeated GitHub API and avatar lookups across many pages ⏱️.
• 🌐 More robust networking: Request timeouts and cached default avatar handling help prevent docs builds from stalling due to network issues 🔒.
• 🔁 Behavioral note for integrators: Author data is now generated centrally (via resolve_all_authors()), so code paths expecting per-file author resolution during HTML processing will no longer run—authors must already be present in git_data 📌.

[UltralyticsAssistant]

👋 Hello @glenn-jocher, thank you for submitting a ultralytics/mkdocs 🚀 PR! This is an automated message—an engineer will review and assist shortly. 🧩

-✅ Define a Purpose: Clearly explain the purpose of your fix or feature in your PR description, and link to any relevant issues. Ensure your commit messages are clear, concise, and adhere to the project's conventions.
-✅ Synchronize with Source: Confirm your PR is synchronized with the ultralytics/mkdocs main branch. If it's behind, update it by clicking the 'Update branch' button or by running git pull and git merge main locally.
-✅ Ensure CI Checks Pass: Verify all Ultralytics Continuous Integration (CI) checks are passing. If any checks fail, please address the issues.
-✅ Update Documentation: Update the relevant documentation for any new or modified features.
-✅ Add Tests: If applicable, include or update tests to cover your changes, and confirm that all tests are passing.
-✅ Sign the CLA: Please ensure you have signed our Contributor License Agreement if this is your first Ultralytics PR by writing "I have read the CLA Document and I sign the CLA" in a new message.
-✅ Minimize Changes: Limit your changes to the minimum necessary for your bug fix or feature addition. "It is not daily increase but daily decrease, hack away the unessential. The closer to the source, the less wastage there is." — Bruce Lee

For more guidance, please refer to our Contributing Guide. Don't hesitate to leave a comment if you have any questions. Thank you for contributing to Ultralytics! 🚀

[UltralyticsAssistant]

🔍 PR Review

_{Made with ❤️ by Ultralytics Actions}

Good refactor overall: moving author resolution to a single main-process pass and having workers consume pre-resolved authors should eliminate the cache write race.

Main items to address: ensure deterministic cache writes by iterating emails in sorted order, add timeouts to GitHub network calls to avoid hanging builds, and normalize/handle empty email keys to preserve prior default_author behavior.

💬 Posted 4 inline comments

[UltralyticsAssistant]

Merged and looking great, @glenn-jocher — thank you for pushing this through. This PR is a solid quality win for the mkdocs pipeline: pre-resolving authors in the main process neatly eliminates parallel cache write conflicts, the 0.2.4 bump keeps releases crisp, and the new cache helpers + request timeouts make builds both faster and far more resilient.

“If I have seen further it is by standing on the shoulders of giants.” — Isaac Newton

This change feels exactly like that: small, thoughtful engineering that quietly lifts everyone’s day-to-day—more reliable parallel docs builds, fewer flaky failures, and smoother postprocessing at scale. Appreciate the care and craftsmanship you bring to the Ultralytics ecosystem.