fix(monitor): fetch_openapi.sh silently writes empty file for specs >1MB

[pythoninthegrass]

Problem

The monitor workflow and scripts/fetch_openapi.sh both silently produce 0-byte spec files for Dokploy v0.29.0+.

Root cause: fetch_openapi.sh uses the GitHub Contents API:

gh api "repos/Dokploy/dokploy/contents/openapi.json?ref=${TAG}"   --jq '.content' | base64 -d | jq . > "$OUTFILE"

The Contents API only returns base64-encoded content for files ≤1MB. The Dokploy openapi.json grew past 1MB between v0.28.8 (578KB) and v0.29.0 (~1.3MB). For larger files the API sets content: "" and provides a download_url instead — so base64 -d decodes nothing and jq . writes an empty string, leaving a 0-byte file with no error.

Affected specs: all of schemas/src/openapi_0.29.*.json (all 0B).

Fix

Switch to download_url in fetch_openapi.sh:

gh api "repos/Dokploy/dokploy/contents/openapi.json?ref=${TAG}"   --jq '.download_url'   | xargs curl -s | jq . > "$OUTFILE"

Also add a size guard — exit non-zero if the output file is 0 bytes so the monitor workflow fails visibly rather than committing an empty file and marking the spec as "already exists" on the next run.

Impact

• schemas/src/openapi_0.29.{0..8}.json are all 0B and must be re-fetched.
• The monitor workflow has not created valid tracking issues since v0.29.0.
• Any API validation done against these schemas has been silently skipped.

Steps to reproduce

./scripts/fetch_openapi.sh v0.29.8
wc -c schemas/src/openapi_0.29.8.json  # 0