DRep metadata never loads for anchors hosted on dreptalk.com although the metadata validates fine

[katomm]

Hello, I just noticed that GovTool shows no metadata (no givenName, no image, no references) for any DRep whose on-chain anchor is hosted on dreptalk.com. This affects all 8 such DReps on mainnet, the oldest registered 2026-06-14, the newest 2026-08-15. Other tools (Tempo.vote, Koios-based explorers) display the same DReps with full metadata.

Example DRep: drep1ygnw2fxf00pqwd3dmnluhf3vd06lrmmvxpmx8chjup4x3pcafs46n (CIP-105: drep1ymjjfjtmcgrnvtwull96vtrt7hc77mpswe379uhqdf5gwr3mmat), anchor https://dreptalk.com/drep/d5eb4bfe6c4b2670c5b38d7618dc473ac1bffaa90e2baf70425135ce292c408f.json.

What I verified

The hosted metadata is valid. The served bytes match the on-chain blake2b-256 hash exactly and the document is valid CIP-119 with content-type: application/json:

$ curl -s https://dreptalk.com/drep/d5eb4bfe6c4b2670c5b38d7618dc473ac1bffaa90e2baf70425135ce292c408f.json | b2sum -l 256
d5eb4bfe6c4b2670c5b38d7618dc473ac1bffaa90e2baf70425135ce292c408f

GovTool's own metadata-validation service accepts it:

$ curl -s -X POST https://gov.tools/metadata-validation/validate -H "content-type: application/json" \
  -d '{"url":"https://dreptalk.com/drep/d5eb4bfe6c4b2670c5b38d7618dc473ac1bffaa90e2baf70425135ce292c408f.json","hash":"d5eb4bfe6c4b2670c5b38d7618dc473ac1bffaa90e2baf70425135ce292c408f","standard":"CIP119"}'
{"valid":true,"metadata":{"givenName":"ADAtainment",...}}

But the backend list API has no metadata for it:

$ curl -s "https://gov.tools/api/drep/list?search=26e524c97bc207362ddcffcba62c6bf5f1ef6c307663e2f2e06a6887"

returns the DRep with "url": null, "metadataHash": null, "givenName": null, "metadataError": null, although the latest on-chain registration cert (2026-06-22, and all three earlier certs too) carries a valid anchor.

Independent db-sync instances fetch these anchors without problems. Koios /drep_metadata returns meta_json with is_valid: true for all 8 affected DReps, including one registered on 2026-08-15, so the standard cardano-db-sync off-chain fetcher handles this host fine.

The host does not block the fetcher. I reproduced the exact request shape of the db-sync off-chain fetcher (HTTP/1.1, no User-Agent, no Accept, Accept-Encoding: gzip, content-type: application/json on the GET) and always get HTTP 200 with the correct bytes. There is no bot protection or WAF rule on the zone.

Where I think the problem comes from

list-dreps.sql only surfaces metadata when the backend's own db-sync instance has a row in off_chain_vote_data for the anchor. For every dreptalk.com anchor since 2026-06-14 that row seems to be missing, while anchors on other hosts registered as recently as 2026-08-11 (GitHub raw, IPFS gateways, self-hosted domains) are picked up normally. Since db-sync retries failed fetches indefinitely (capped at one retry per day), a transient failure would have healed long ago. This looks like the backend's db-sync instance persistently cannot reach dreptalk.com specifically, for example an egress DNS filter or a newly-registered-domain block in that environment.

Could you check off_chain_vote_fetch_error on the production db-sync instance for these anchor URLs? The recorded fetch_error should show exactly why the fetch fails there. Thanks.

Affected mainnet anchors

All are https://dreptalk.com/drep/<hash>.json with matching content, first seen between 2026-06-14 and 2026-08-15:

edf30750e496146fae3dfd07c634802392e15d8d8f8a86c3647829bebb6466b0
babeece9b8ad3ec473c39404ad95f6d0da74b9dd5553af4597fc75119759f736
4df8f355c981410e879905d623fac674e13f498d8b7dd5cf914d17ebf85057a2
d5eb4bfe6c4b2670c5b38d7618dc473ac1bffaa90e2baf70425135ce292c408f
dc567dd4517133f56accd9402f69c7b3b18350467762910a8dc534f59a617275
c54d59017aa9546662899d95d9b24c553a64cb7e4c182bb9d1a2bc98b8696795
09ba86de731a71df6521dd12939cf04d1456d87d876f2950f7ccad64a579ab95
fd9c9a47ee1eb5557258323139d3b3262c1355e85f57dee270476cbe02f1b0e0
8f611ea71e83692906f9232c9c957ac1fe4e5d40a471ca8c540ad12804e017ed
587580caf65b4f9d2fcd5df5ccdeb4f3bf8dae743924bd7314be8ec0d6724bba
7b915f851433754dcc7a88e0f37660ae03b87e44ff56cca87f196f98c453a44f
0a2916f6506894bff74c1567ca9519e73534d8d3e583726f3e6755f6c3372e45