Activity

1. stdlib-bot

   added

   Good First IssueA good first issue for new contributors!A good first issue for new contributors!

   on Apr 1, 2026
2. stdlib-bot

   added a parent issue on Apr 1, 2026

   • Tracking issue: Fix broken links in Markdown files #9112
3. stdlib-bot commented on Apr 1, 2026

   

   stdlib-bot

   on Apr 1, 2026

   ContributorAuthor

   More actions

   👋 Important: PLEASE READ 👋

   This issue has been labeled as a good first issue and is available for anyone to work on.

   If this is your first time contributing to an open source project, some aspects of the development process may seem unusual, arcane, or some combination of both.

   1. You cannot "claim" issues. People new to open source often want to "claim" or be assigned an issue before beginning work. The typical rationale is that people want to avoid wasted work in the event that someone else ends up working the issue. However, this practice is not effective in open source, as it often leads to "issue squatting", in which an individual asks to be assigned, is granted their request, and then never ends up working on the issue. Accordingly, you are encouraged to communicate your intent to address this issue, ideally by providing a rough outline as to how you plan to address the issue or asking clarifying questions, but, at the end of the day, we will take running code and rough consensus in order to move forward quickly.
   2. We have a very high bar for contributions. We have very high standards for contributions and expect all contributions—whether new features, tests, or documentation—to be rigorous, thorough, and complete. Once a pull request is merged into stdlib, that contribution immediately becomes the collective responsibility of all maintainers of stdlib. When we merge code into stdlib, we are saying that we, the maintainers, commit to reviewing subsequent changes and making bugfixes to the code. Hence, in order to ensure future maintainability, this naturally leads to a higher standard of contribution.

   Before working on this issue and opening a pull request, please read the project's contributing guidelines. These guidelines and the associated development guide provide important information, including links to stdlib's Code of Conduct, license policy, and steps for setting up your local development environment.

   To reiterate, we strongly encourage you to refer to our contributing guides before beginning work on this issue. Failure to follow our guidelines significantly decreases the likelihood that you'll successfully contribute to stdlib and may result in automatic closure of a pull request without review.

   Setting up your local development environment is a critical first step, as doing so ensures that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. If you would prefer to avoid manual setup, we provide pre-configured development containers for use locally or in GitHub Codespaces.

   We place a high value on consistency throughout the stdlib codebase. We encourage you to closely examine other packages in stdlib and attempt to emulate the practices and conventions found therein.

   • If you are attempting to contribute a new package, sometimes the best approach is to simply copy the contents of an existing package and then modify the minimum amount necessary to implement the feature (e.g., changing descriptions, parameter names, and implementation).
   • If you are contributing tests, find a package implementing a similar feature and emulate the tests of that package.
   • If you are updating documentation, examine several similar packages and emulate the content, style, and prose of those packages.

   In short, the more effort you put in to ensure that your contribution looks and feels like stdlib—including variables names, bracket spacing, line breaks, etc—the more likely that your contribution will be reviewed and ultimately accepted. We encourage you to closely study the codebase before beginning work on this issue.

   ✨ Thank you again for your interest in stdlib, and we look forward to reviewing your future contributions. ✨
4. MANDEep22332 commented on Apr 1, 2026

   

   MANDEep22332

   on Apr 1, 2026

   Contributor

   More actions

   link is live @stdlib-bot
5. abhiravi1912 commented on Jun 1, 2026

   

   abhiravi1912

   on Jun 1, 2026

   More actions

   The link appears to be live and loading correctly.
   The 502 error was likely a temporary issue at the time
   of the automated check. No fix needed.
6. udit19199 commented on Aug 4, 2026

   

   udit19199

   on Aug 4, 2026

   Contributor

   More actions

   Here is what seems to be going wrong and why.

   What is happening
   Temporary 502 Bad Gateway error from Bugzilla servers triggered issue creation due to inadequate error classification system that treats temporary infrastructure failures as permanent link rot

   1. Why was there a broken Markdown link reported?
      Automated workflow detected HTTP 502 error accessing https://bugzilla.mozilla.org/show_bug.cgi?id=892671
      Evidence: Case Fix pi link address in sincospi readme #131 description: 'HTTP Status: 502 (Unknown HTTP Status Code)' at 2026-08-04T11:10:33.085000
   2. Why did the link return 502?
      Bugzilla servers temporarily returned '502 Bad Gateway' error due to infrastructure issues
      Evidence: Current curl test shows HTTP 200 OK, confirming temporary nature
   3. Why would a temporary server error trigger a broken link report?
      Link checking system lacks comprehensive error classification to distinguish temporary infrastructure failures from permanent link rot
      Evidence: Issue creation script at .github/workflows/scripts/markdown_links/create_broken_link_issues:335-350 shows partial classification (skips 429/403 but not 502/503/504)

   Not confirmed: Investigation includes unproven claim about retry logic (link 4) without evidence; deepest proven cause is inadequate error classification

   I put this together with Operate (https://operatex.dev), an AI tool that reads the code and traces the likely cause, and reviewed it before posting.
7. udit19199 commented on Aug 4, 2026

   

   udit19199

   on Aug 4, 2026

   Contributor

   More actions

   I don't think the Markdown link itself is broken. I'd like to investigate whether this is instead an issue with how the link-checking workflow handles transient HTTP errors. If so, the appropriate fix would likely be a separate issue against the workflow rather than this Markdown link.
8. udit19199 commented on Aug 4, 2026

   

   udit19199

   on Aug 4, 2026

   Contributor

   More actions

   Follow-up after reviewing the workflow and the upstream checker source:

   The retry behavior is handled by stdlib-js/check-markdown-link-definitions-action, which performs a single curl request per URL and has no retry or timeout handling:

   https://github.com/stdlib-js/check-markdown-link-definitions-action/blob/main/check_links.sh#L159-L175

   Its default success/warning configuration does not include 5xx responses, so a temporary 502 is emitted as a failure:

   https://github.com/stdlib-js/check-markdown-link-definitions-action/blob/main/action.yml#L11-L18

   The stdlib workflow then fails on that output and invokes create_broken_link_issues. That script currently filters only 403 and 429, so the 502 is allowed to create a broken-link issue:

   https://github.com/stdlib-js/stdlib/blob/develop/.github/workflows/markdown_links.yml#L155-L179
   https://github.com/stdlib-js/stdlib/blob/develop/.github/workflows/scripts/markdown_links/create_broken_link_issues#L335-L350

   This confirms that the Markdown link itself does not need to be changed. The underlying issue is transient HTTP failures being treated as confirmed broken links by the automated workflow. Any fix should be tracked separately as workflow/action infrastructure work. I’m unable to continue working on this, but I wanted to provide the confirmed findings for maintainers.

   👍React with 👍1Reacted by Kanika Sharma
9. anithawork2101-dotcom commented on Oct 9, 2026

   

   anithawork2101-dotcom

   on Oct 9, 2026

   More actions

   Hi, I'd like to work on this issue as my first contribution to stdlib. I'll verify the broken link and investigate whether a suitable replacement is available.
10. anithawork2101-dotcom commented on Oct 9, 2026

    

    anithawork2101-dotcom

    on Oct 9, 2026

    More actions

    Hi, I'd like to work on this issue as my first contribution to stdlib. I've verified that the Bugzilla issue is accessible and that archived snapshots are available. I'll investigate the best way to address the reported link-checking failure.
11. kanikasharma-18 commented on Oct 16, 2026

    

    kanikasharma-18

    on Oct 16, 2026

    Contributor

    More actions

    I looked into this locally, and the findings seem consistent with what @udit19199 pointed out. The create_broken_link_issues script skips 403 and 429 but doesn't appear to handle 502 or other 5xx responses similarly. The Bugzilla URL also currently returns 200 OK in my curl test.

    Would it make sense to track this as a separate workflow issue?

    Thanks!