badges/shields · error · Error

Should not get here due to validation

Error message

Should not get here due to validation

What it means

In uptimerobot-status.service.js, render() maps a UptimeRobot monitor status code to a message/color pair via a switch. Codes outside the validated range (0/1/2/8/9) reach the default case, where the service throws this plain Error. It should be unreachable because handle() validates the status value upstream, so it signals an internal invariant violation or an unanticipated API status code.

Source

Thrown at services/uptimerobot/uptimerobot-status.service.js:50

    status,
    upMessage = 'up',
    downMessage = 'down',
    upColor = 'brightgreen',
    downColor = 'red',
  }) {
    switch (status) {
      case 0:
        return { message: 'paused', color: 'yellow' }
      case 1:
        return { message: 'not checked yet', color: 'yellowgreen' }
      case 2:
        return { message: upMessage, color: upColor }
      case 8:
        return { message: 'seems down', color: 'orange' }
      case 9:
        return { message: downMessage, color: downColor }
      default:
        throw Error('Should not get here due to validation')
    }
  }

  async handle(
    { monitorSpecificKey },
    {
      up_message: upMessage,
      down_message: downMessage,
      up_color: upColor,
      down_color: downColor,
    },
  ) {
    const { monitors } = await this.fetch({ monitorSpecificKey })
    const { status } = monitors[0]
    return this.constructor.render({
      status,
      upMessage,
      downMessage,

View on GitHub (pinned to 766fd8bc89)

Solutions

1. Log the actual status code to identify the uncovered value, then add a switch case mapping it to a message/color
2. Wrap the value in handle()'s validation so unknown codes fall back to a neutral 'unknown' badge state instead of throwing
3. Catch the error in handle() and render a default 'unknown' response

Example fix

// before
case 9:
  return { message: downMessage, color: downColor }
default:
  throw Error('Should not get here due to validation')
// after
case 9:
  return { message: downMessage, color: downColor }
default:
  return { message: 'unknown status', color: 'lightgrey' }

const KNOWN_STATUSES = [0, 1, 2, 8, 9]
if (!KNOWN_STATUSES.includes(monitor.status)) {
  console.warn(`Unrecognized UptimeRobot status: ${monitor.status}`)
}

function isKnownUptimeRobotStatus(status) {
  return [0, 1, 2, 8, 9].includes(status)
}

try {
  return await uptimerobotStatusService.handle(config, props)
} catch (err) {
  if (err.message === 'Should not get here due to validation') {
    return { message: 'unknown status', color: 'lightgrey' }
  }
  throw err
}

When it happens

Trigger: UptimeRobot API returns a monitor status code not covered by the switch (e.g. a newly introduced status code, or a code like 7 for check-timeout that slipped past validation) so it reaches the default case in render().

Common situations: UptimeRobot adds or documents a new status code after this badge was written; a mocked/tested API returns an unexpected integer; upstream validation is loosened during a refactor and an unusual code slips through.

Related errors

• WordPress version API response: ${error.message}

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