🐛 Bug - API rate limit error displayed in rating and commenting section

[tiagov8]

Requested by: @tiagov8 via YakShaver.ai 🦬
cc: @tiagov8, @Marxoz, @PothieuG, @Freego1783 @adamcogan @Aibono1225

Hi Team!

  🟥  Watch the video (44 sec)

  Url from screen share: https://ssw.com.au/rules/untapped-keywords

Pain

Users are encountering an API rate limit error when viewing rules in the Rules V3 (TinaCMS) project. The issue appears to occur within the rating and commenting section and is reproducible across multiple rules. Investigate the source of the excessive API requests or incorrect rate limiting behavior and implement a fix so users can view and interact with rules without errors.

Acceptance Criteria

1. Users can open rule pages without seeing the API rate limit exceeded error.
2. The rating and commenting section loads successfully for all rules.
3. API requests related to ratings and comments are optimized to prevent unnecessary rate limit usage.
4. Proper error handling is implemented if the API rate limit is genuinely exceeded.
5. The fix is validated across multiple rule pages in Rules V3 (TinaCMS).

Reproduce Steps

1. Open the Rules V3 (TinaCMS) website.
2. Navigate to any rule page.
3. Observe the error message displayed in the rating and commenting section.
4. Open additional rule pages.
5. Confirm the same API rate limit exceeded error appears consistently.

Screenshot

Figure: API rate limit exceeded error in rule rating and commenting section

[github-actions]

🔍 Research Findings

Summary

The "rating and commenting section" is the Giscus widget (components/Discussion.tsx), which uses GitHub Discussions as the backend. It makes unauthenticated GitHub API requests from users' browsers — GitHub's unauthenticated rate limit is 60 requests/hour per IP. Users on shared networks (offices, schools) or users who open many rule pages quickly can hit this limit and see the error.

---

Similar Issues

No existing duplicates found.

---

Relevant Files

File	Role
components/Discussion.tsx	Giscus widget — the "rating and commenting section"
app/[filename]/ServerRulePage.tsx	Rule page layout, renders <Discussion> twice

---

Root Cause Analysis

1. Double rendering of <Discussion> in ServerRulePage.tsx

The Discussion component is mounted in two places simultaneously:

// Desktop (line ~101): shown on md+, hidden on mobile
<div className="hidden md:block">
  <Discussion ruleGuid={rule?.guid || ""} />
</div>

// Sidebar (line ~117): shown on mobile, hidden on md+
<div className="block md:hidden">
  <Discussion ruleGuid={rule.guid} />
</div>

While loading="lazy" and display: none should prevent the hidden instance from firing requests, both custom elements (<giscus-widget>) are still mounted in the DOM. In some browsers or edge cases (e.g., viewport resize), both could initialise and double the GitHub API calls per page load.

2. No env var validation before rendering

Discussion.tsx will attempt to render Giscus even when NEXT_PUBLIC_GISCUS_REPO_ID or NEXT_PUBLIC_GISCUS_CATEGORY_ID are empty strings, leading to invalid API requests:

repoId={process.env.NEXT_PUBLIC_GISCUS_REPO_ID || ""}   // falls back to "" — renders anyway
categoryId={process.env.NEXT_PUBLIC_GISCUS_CATEGORY_ID || ""}  // same

If these vars are misconfigured in any environment, Giscus may retry API calls aggressively and burn through the rate limit quickly.

3. No user-friendly fallback

When Giscus fails (rate limit or otherwise), the error is displayed raw inside the Giscus iframe. There's no wrapper-level fallback to show a link to the GitHub Discussion page directly.

---

Potential Approaches

Option A — Fix double rendering (lowest risk, highest impact)

Replace the two conditional Discussion instances with a single one and use CSS only where needed, or use a client component with useMediaQuery to render just one instance. This removes any chance of double API requests.

Option B — Add env var guards (easy win)

In Discussion.tsx, validate all required env vars before rendering:

const repo = `${process.env.NEXT_PUBLIC_GITHUB_ORG}/${process.env.NEXT_PUBLIC_GISCUS_REPO_NAME}`;
const repoId = process.env.NEXT_PUBLIC_GISCUS_REPO_ID || "";
const categoryId = process.env.NEXT_PUBLIC_GISCUS_CATEGORY_ID || "";

if (isDev || !ruleGuid || !repoId || !categoryId || !process.env.NEXT_PUBLIC_GITHUB_ORG || !process.env.NEXT_PUBLIC_GISCUS_REPO_NAME) {
  return null;
}

Option C — Listen for Giscus window.postMessage errors

Giscus emits postMessage events from its iframe. We could add a listener in Discussion.tsx to detect error states and render a fallback link to the GitHub Discussion:

// e.g., https://github.com/{org}/{giscus-repo}/discussions

Option D — Server-side discussions proxy (highest effort)

Cache GitHub Discussion data server-side (like discussions.service.ts does for the homepage) and serve it with unstable_cache. This eliminates unauthenticated client-side requests entirely. However, this is a significant architectural change.

---

Open Questions

1. Is NEXT_PUBLIC_GISCUS_REPO_ID correctly set in all environments? — An empty or placeholder value would cause Giscus to fail on every page load.
2. What's the exact error message in the Giscus iframe? — If it says "Discussion not found" vs "Rate limit exceeded", the root cause differs.
3. Is the double <Discussion> rendering actually initialising twice? — Can be confirmed by checking Network tab in DevTools (how many requests to api.github.com per page load).

---

Confidence: ~55% (Low)

The Giscus rate limit is an external constraint hard to fix without server-side caching or OAuth. The double rendering and missing env var guards are concrete code fixes, but they may only partially reduce the symptom. A proper investigation with DevTools Network tab and confirmation of env var values in production would significantly narrow down the root cause.

Generated by Issue Triage for issue #2676 · ● 993K · ◷