Tool discovery (`full` workflow) has failed on every scheduled run since 2025-07-13 — dead source URL in metadata.json

Summary

The full workflow — the one that discovers new tools — has failed on every scheduled run in the retained history: 59 consecutive failures, the oldest dating to 2025-07-13. There is not a single success on record.

metadata.yaml (Mon–Sat) continues to succeed daily, so existing entries keep refreshing and the site looks healthy. Only discovery is broken, which makes this easy to miss.

Evidence

Most recent run: #239, 2026-08-23 — job get-data-from-sources, failing step Run yarn run build:data:full:

[03:53:08] 'full' errored after 302 ms
[03:53:08] Error in plugin 'gulp-transform'
    Request failed with status code 404
    isAxiosError: true

It fails after ~300ms, i.e. on the first HTTP request rather than partway through a harvest.

Root cause

The first entry in gulpfile.js/metadata.json is:

{
  "title": "https://openapi.tools/",
  "url": "https://raw.githubusercontent.com/apisyouwonthate/openapi.tools/master/_data/tools.yml",
  "processor": "../processors/openapi-tools-processor.js"
}

That URL is dead. apisyouwonthate/openapi.tools has restructured:

So it is not just a branch rename: the single aggregated tools.yml no longer exists in any branch. Each tool is now its own markdown file with YAML front matter.

Impact

Repositories tagged openapi3 / openapi31 per the README are never picked up, because the run aborts before reaching the tagged-repository-processor sources.

This appears to be why several "Add …" issues have sat open — the authors followed the documented process correctly and nothing happened: #282, #281, #273, #272, #270, #255, #211, #193, #191, #190, #189, #188.

Possible fixes

1. Point the processor at the new layout — enumerate src/content/tools/*.md (via the GitHub contents API or a tarball) and parse each file's front matter, replacing openapi-tools-processor.js's single-file assumption.
2. Make source fetches non-fatal — a 404 from one source currently aborts the whole build, so the openapi3 / openapi31 topic harvest never runs even though it is independent and presumably still healthy. Failing soft per-source would have kept discovery alive for the last 13 months and made this visible far sooner.

(2) looks worth doing regardless of (1), since it limits the blast radius of any future upstream change.

I'm happy to open a PR if that would help — just say which direction you'd prefer.

How I found this

I tagged my own repositories with openapi3 / openapi31 as the README describes, noticed nothing appeared, and went looking for why. Reporting it here rather than adding another "Add my tool" issue, since this looks like the thing blocking all of them.

Start with gulpfile.js/metadata.json and processors/openapi-tools-processor.js, then run the build:data:full workflow to reproduce the 404. Determine how the changed src/content/tools/*.md layout or per-source failure handling should be supported. Done means full discovery completes without the dead source blocking tagged-repository-processor sources.