Refactor contributors list & fetch wrapper [i18nIgnore]

[HiDeoo]

Description (required)

The issue has been found and is related to a request to the GitHub API to fetch contributors returning a 403 status code.

The issue will not be fixed in this PR but I'm keeping the investigation notes here for reference and also as a reminder to refactor this part of the code to add more logging when fetching failures happen and also revisit the retry logic (the default settings exceeds the Netlify build time limit).

Run	Status	Details
1	❌	Logs stopped when rendering "Contribute to Astro"
2	❌	Logs stopped when rendering (renderToString) "Contribute to Astro"
3	❌	Logs stopped when starting to fetch contributors
4	❌	Fetch contributors in a retry loop (default 10) with exponential backoff
5	❌	Bad response for https://api.github.com/repos/withastro/docs/contributors (403): Forbidden

Related issues & labels (optional)

• Closes #
• Suggested label:

[netlify]

✅ Deploy Preview for astro-docs-2 ready!

Name	Link
🔨 Latest commit	e023229
🔍 Latest deploy log	https://app.netlify.com/projects/astro-docs-2/deploys/68eb827a1b21630008382863
😎 Deploy Preview	https://deploy-preview-12530--astro-docs-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[delucis]

I confirmed this was a token issue and updating our token fixed deploys.

Nonetheless, some good action items we should look at coming out of this:

1. Move to collect GitHub contributor data in a GitHub workflow instead of with every build:

   • Remove the build-time calls to the GitHub API
   • Create a GitHub workflow that runs weekly (?) that fetches the data and stores it in the repo as JSON
   • Update the component to use that data instead

   Means everyone can render the component locally, and no need for tokens anywhere except for on GitHub where we get one for free.

2. Add logging to our fetch wrapper (which adds retries/caching) to ensure that cases like this will be easier to diagnose in the future.

[astrobot-houston]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
ar/contribute.mdx	Localization changed, will be marked as complete.
de/contribute.mdx	Localization changed, will be marked as complete.
es/contribute.mdx	Localization changed, will be marked as complete.
fr/contribute.mdx	Localization changed, will be marked as complete.
hi/contribute.mdx	Localization changed, will be marked as complete.
it/contribute.mdx	Localization changed, will be marked as complete.
ja/contribute.mdx	Localization changed, will be marked as complete.
ko/contribute.mdx	Localization changed, will be marked as complete.
pl/contribute.mdx	Localization changed, will be marked as complete.
pt-br/contribute.mdx	Localization changed, will be marked as complete.
ru/contribute.mdx	Localization changed, will be marked as complete.
zh-cn/contribute.mdx	Localization changed, will be marked as complete.
zh-tw/contribute.mdx	Localization changed, will be marked as complete.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[HiDeoo]

Updated the PR based on your recommendations:

• Cleanup all logs I introduced for investigation.
• Move contributors data to a file content collection:
  • The file updated weekly as you suggested but we can discuss the schedule if needed.
  • We only store the data we really need (e.g. not the number of contributions which will make diffs a bit easier — I guess showing (and storing) contributors alphabetically rather than number of contributions would make this even easier if we wanted).
• I removed some unused code (<TranslatorList/>).
• I tweaked our cachedFetch utility:

  • I added logs on failed attempts to fetch data including the attempt number and retries left.

  • I tweaked the exponential backoff settings:

    The formula is: Math.round(random * minTimeout * (factor ** (attempt - 1)))
    With the defaults settings, this gives us: Math.round(1 * 1000 * (2 ** (attempt - 1)));

    Attempt/Retry	Exponential Backoff Time
    attempt 1
    attempt 2 - retry 1	1s
    attempt 3 - retry 2	2s
    attempt 4 - retry 3	4s
    attempt 5 - retry 4	8s
    attempt 6 - retry 5	16s
    attempt 7 - retry 6	32s
    attempt 8 - retry 7	1m04s
    attempt 9 - retry 8	2m08s
    attempt 10 - retry9	4m16s
    attempt 11 - retry 10	8m32s

    This is a lot and in case of failure, Netlify will timeout the build before we reach the max retries of 10.

    I set the max retries to 5 with a factor of 3 so the new settings give us:

    Attempt/Retry	Exponential Backoff Time
    attempt 1
    attempt 2 - retry 1	1s
    attempt 3 - retry 2	2s
    attempt 4 - retry 3	9s
    attempt 5 - retry 4	27s
    attempt 6 - retry 5	1m21s

    Concretely, this means the first attempts happens like before, very quickly. Then if it fails, we wait a lot more between retries, and just give up way earlier.

    Happy to discuss/adjust these settings of course.

[delucis]

This looks fantastic @HiDeoo! +1 to the retry logic and nice work moving this to a workflow. Great to see it cleaned up.

We only store the data we really need (e.g. not the number of contributions which will make diffs a bit easier — I guess showing (and storing) contributors alphabetically rather than number of contributions would make this even easier if we wanted).

Off the top of my head, we ultimately render in order from most contributions to least, so I guess we have two options here:

1. Store pre-sorted contributors — only requires storing usernames.
2. Store alphabetically sorted contributors — would require storing username + contribution count.

I don’t have strong opinions on which is better. Option 1 I guess will result in a slightly messier diff as entries move up and down, while option 2 will be more stable but all contributors in a week will show up as their contribution count changes.

One thought though: we’re not using the id field right? Why not make the login value the id and just use that? So with the current approach the file would look like:

[
  {
    "id": "jsparkdev"
  },
  {
    "id": "ArmandPhilippot"
  },
  {
    "id": "sarah11918"
  },
  // etc.
]

Or if we included a count:

[
  {
    "id": "ArmandPhilippot",
    "count": 100
  },
  {
    "id": "jsparkdev",
    "count": 1000
  },
  {
    "id": "sarah11918",
    "count": 500
  },
  // etc.
]

There’s also another option, which is to not bother with content collections for this and just store:

[
  "jsparkdev",
  "ArmandPhilippot",
  "sarah11918",
  // etc.
]

The component could just import the JSON file for this one — we don’t really need the content collection features.