badges/shields · warning · Error

WordPress version API response: ${error.message}

Error message

WordPress version API response: ${error.message}

What it means

getOfferedVersions() in services/wordpress-version-color.js fetches WordPress core version data from api.wordpress.org and validates the JSON with a schema inside the scraper. When the API response shape does not match (missing offers, non-string versions, unexpected structure), it throws this Error with the schema validation message. It wraps upstream API contract changes into a descriptive error.

Source

Thrown at services/wordpress/wordpress-version-color.js:26

    offers: Joi.array()
      .items(
        Joi.object()
          .keys({
            version: optionalDottedVersionNClausesWithOptionalSuffix,
          })
          .required(),
      )
      .required(),
  })
  .required()

async function getOfferedVersions() {
  return getCachedResource({
    url: 'https://api.wordpress.org/core/version-check/1.7/',
    scraper: json => {
      const { error, value } = schema.validate(json, { allowUnknown: true })
      if (error) {
        throw Error(`WordPress version API response: ${error.message}`)
      }
      return value.offers.map(v => v.version)
    },
  })
}

function toSemver(v) {
  const parts = v.split('-')
  if (parts.length > 2) {
    return v
  }
  const version = parts[0]
  const suffix = parts[1] ? parts[1] : ''
  if (version.split('.').length === 2) {
    return suffix !== '' ? `${version}.0-${suffix}` : `${version}.0`
  } else {
    return v
  }

View on GitHub (pinned to 766fd8bc89)

Solutions

  1. Inspect error.message to see which schema constraint failed and compare with the current API response shape
  2. Add/adjust the schema (with allowUnknown) to tolerate new optional fields or the new response structure
  3. Add retry/backoff via the caching layer for transient failures, and catch the error upstream to serve a cached or fallback version list

Example fix

// before
const { error, value } = schema.validate(json, { allowUnknown: true })
if (error) {
  throw Error(`WordPress version API response: ${error.message}`)
}
return value.offers.map(v => v.version)
// after
const { error, value } = schema.validate(json, { allowUnknown: true })
if (error) {
  throw new InvalidResponse({ prettyMessage: `WordPress version API response: ${error.message}` })
}
return (value.offers || []).map(v => v.version)
Defensive patterns

Strategy: retry

Validate before calling

if (!json || !Array.isArray(json.offers)) {
  throw new Error('Unexpected WordPress version API payload: missing offers array')
}

Type guard

function isValidWordPressVersionResponse(json) {
  return typeof json === 'object' && json !== null &&
    Array.isArray(json.offers) &&
    json.offers.every(o => typeof o?.version === 'string')
}

Try / catch

try {
  return await getOfferedVersions()
} catch (err) {
  if (err.message.startsWith('WordPress version API response:')) {
    // transient/contract issue: use cached or empty fallback
    return cachedVersions ?? []
  }
  throw err
}

Prevention

When it happens

Trigger: The WordPress version-check/1.7 endpoint returns JSON failing schema.validate — e.g. the response omits the 'offers' array, offers lack a 'version' field, or a non-JSON error page is somehow parsed.

Common situations: WordPress changes its core/version-check/1.7 API format; the API returns a maintenance or error payload; a proxy/firewall returns an HTML error page instead of JSON; transient network failures yield truncated responses.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

AI-assisted analysis of badges/shields@766fd8bc89 (2026-08-30). Data as JSON: /api/errors/7f52b04aa9d18dd3. Report an issue: GitHub.