Broken link: regex-golang.appspot.com (Go regex tester) is dead

[jstirnaman]

Broken link

https://regex-golang.appspot.com/assets/html/index.html returns 404. The
App Engine app appears to be gone.

Where

Both files list it under a "Go regex testers" heading:

• content/shared/influxdb-v1/flux/guides/regular-expressions.md
• content/shared/influxdb-v2/query-data/flux/regular-expressions.md

Each also links Regex101, which is healthy (200) and
supports Go/RE2, so readers are not left without a tool.

Why this is filed rather than fixed inline

Choosing a replacement is an editorial call, not a mechanical one — the options
differ in whether they support RE2 specifically. Candidates worth considering:

• https://regex101.com/ with the Golang flavor selected (already linked)
• https://goplay.tools/ or the Go Playground for regexp snippets

Filing under area:links so pr-link-check.yml downgrades it to a warning
while the replacement is decided, instead of blocking unrelated PRs that happen
to touch these pages.

Found via

Surfaced by #7622, which migrated the v1 copy into shared content. The link
checker only inspects changed files, so pages that had not been edited in a
while were never checked — this URL has presumably been dead for some time.

[jstirnaman]

Scope narrowed to the v2 copy.

#7622 removed the dead link from
content/shared/influxdb-v1/flux/guides/regular-expressions.md rather than
waiting on a replacement. Regex101 was already listed on the next line and
supports the Golang/RE2 flavor, so the "Go regex testers" section still points
readers at a working tool. No replacement decision was needed after all.

Remaining: content/shared/influxdb-v2/query-data/flux/regular-expressions.md:72
still links https://regex-golang.appspot.com/assets/html/index.html. The same
one-line removal applies.

---

Separately — the area:links waiver did not work here, and that looks like a
bug worth its own investigation.

pr-link-check.yml fetches open area:links issues and downgrades matching
broken URLs to warnings. With this issue open and correctly labeled, the step
logged:

Loaded 0 open area:links issue(s)

Verified:

• The same query returns this issue:
  gh api "repos/influxdata/docs-v2/issues?labels=area%3Alinks&state=open" → 1.
• Not a timing artifact. The issue was created at 05:03:51Z; the step ran at
  05:07:08Z, and a re-run ~9 hours later still loaded 0.
• Not a swallowed API error. fetchKnownLinkIssues catches and logs via
  console.warn, and no warning or 403 appears anywhere in the job log.
• Not a matcher problem. Running urlMatchesIssueText from
  .github/scripts/link-check-classify.js against this issue's title + body
  returns true.

So the fetch itself returns an empty array. One candidate worth checking first:
the job declares permissions: contents: read and pull-requests: write, which
sets every other scope — including issues — to none, and
issues.listForRepo needs issues: read. That would explain an empty result,
though it would more usually surface as a 403. I did not change the workflow to
test this, since it is outside the scope of #7622.

Net effect: as it stands, filing an area:links issue does not actually stop a
known broken link from failing CI.