API returning HTTP 500 across multiple endpoints (/trends/repos, /repos/{owner}/{repo})

[FenjuFu]

The public API at api.ossinsight.io is returning HTTP 500 across multiple endpoints, while the frontend at ossinsight.io still loads (200). As a result, trending data on the site renders empty.

First observed 2026-06-30 ~01:50 UTC and still failing at ~04:10 UTC (persisted 2+ hours), so this looks like a backend issue rather than a transient spike.

Reproduction:

GET /v1/trends/repos/?period=past_24_hours  -> 500  {"message":"Request failed with status code 400"}
GET /v1/trends/repos/?period=past_week       -> 500  {"message":"Request failed with status code 400"}
GET /v1/trends/repos/?period=past_month      -> 500  {"message":"Request failed with status code 400"}
GET /v1/repos/{owner}/{repo}/                -> 500  (wrapping upstream 400/404; earlier saw 429 on /trends)

The 500 responses wrap an upstream 400/429/404, which points to a backend query-service or rate-limit issue rather than routing. Possibly related to #3084.

Frontend host responds 200; only the data API is affected.

[braxtonliu]

is it broken again or it's never been fixed? lol

[FenjuFu]

Status update after rechecking the public API on 2026-08-17:

• /v1/trends/repos/?period=past_24_hours now returns HTTP 200 JSON;
• /v1/trends/repos/?period=past_week now returns HTTP 200 JSON;
• /v1/repos/pingcap/ossinsight/ still returns HTTP 500, with the response indicating that the upstream request returned 404.

So the trends API has recovered, but the repository-detail path still wraps an upstream 404 as a 500. This issue is therefore partially resolved rather than fully fixed; keeping it open for the repo-specific endpoint still looks appropriate.