Skip to content

API result status discards error details (always "error - temporary") #509

Closed
FrancoStino/github-stats-extended
#45

Description

@luojiyin1987

Summary

All API handlers hardcode status: "error - temporary" in their catch blocks. The real error type and message only survive inside the rendered SVG content. Callers that read result.status cannot tell what went wrong.

Details

Example from packages/core/src/api/index.js:

} catch (err) {
  if (err instanceof Error) {
    return {
      status: "error - temporary",
      ...

This pattern repeats in index.js, gist.js, pin.js, top-langs.js, and wakatime.js.

For unattended jobs this makes diagnosis hard. The log cannot answer:

  • Is it a rate limit?
  • Is it a 502?
  • Is it ECONNRESET?
  • Is it a GraphQL error?
  • Is it a token problem?

Proposal

Keep the legacy prefix for compatibility. Append the error type and message:

error - temporary (MAX_RETRY: Downtime due to GitHub API rate limiting ...)
error - temporary (Missing params "username" ...)
error - temporary (Error: connect ECONNRESET 140.82.x.x:443)

A small helper next to retrieveSecondaryMessage in common/error.ts can build this string for all five handlers.

I have a working implementation and will open a PR.

Activity

  1. luojiyin1987 commented on Aug 24, 2026

    @luojiyin1987
    Author

    Update on the design: the first implementation appended the details to the status string (error - temporary (MAX_RETRY: ...)). Review of that PR showed it breaks the exact status === "error - temporary" comparisons in apps/backend/router.js, which would cache transient errors for 10 hours instead of 10 minutes.

    The final design keeps status stable and adds an optional structured field instead:

    {
      status: "error - temporary",
      error: { type?: string, message: string },
      content: ...
    }

    See PR #511 for the reworked diff.

  2. martin-mfg commented on Aug 24, 2026

    @martin-mfg
    Member

    Thanks for bringing this up and for the corresponding PR!

    I will have to see when I find the time to review and merge the changes. In the meantime the fail_on_error option might be helpful for your situation.

    I would like to better understand what problem you encountered. What kind of "unattended job" are you running - simply github-readme-stats-action? And what caused the temporary error for you?

    PS: Found the answer in vizrtluo#1:

    Unattended GitHub Actions runs fail randomly on transient GitHub API errors.

  3. added a commit that references this issue on Sep 15, 2026
    c5b6b31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions