What causes "Unsupported storage kind:${kind}" in hcengineering/platform?

Set config.kind to a supported value (S3/builtin, datalake, or hulylake kind constant)

Unsupported storage kind:${kind}

Error message

Unsupported storage kind:${kind}

What it means

createStorageFromConfig dispatches on config.kind and only supports the builtin (S3), DATALAKE_CONFIG_KIND and HULYLAKE_CONFIG_KIND branches. Any other kind value falls into the else clause, which throws 'Unsupported storage kind:<kind>'.

Source

Thrown at foundations/server/packages/server-storage/src/starter.ts:108

    const c = config as S3Config
    if (c.endpoint == null || c.accessKey == null || c.secretKey == null) {
      throw new Error('One of endpoint/accessKey/secretKey values are not specified')
    }
    adapter = new S3Service(c)
  } else if (kind === DATALAKE_CONFIG_KIND) {
    const c = config as DatalakeConfig
    if (c.endpoint == null) {
      throw new Error('Endpoint value is not specified')
    }
    adapter = new DatalakeService(c)
  } else if (kind === HULYLAKE_CONFIG_KIND) {
    const c = config as HulylakeConfig
    if (c.endpoint == null) {
      throw new Error('Endpoint value is not specified')
    }
    adapter = new HulylakeService(c)
  } else {
    throw new Error('Unsupported storage kind:' + kind)
  }

  if (config.readonly === 'true') {
    adapter = new ReadonlyStorageAdapter(adapter)
  }

  return adapter
}

export function buildStorageFromConfig (config: StorageConfiguration): FallbackStorageAdapter {
  return buildStorage(config, createStorageFromConfig)
}

View on GitHub (pinned to 63e28dc964)

Solutions

Set config.kind to a supported value (S3/builtin, datalake, or hulylake kind constant)
Log/print the actual kind value to spot typos or undefined
Upgrade the server if the config uses a newer storage kind
Validate kind against the supported list before calling

Example fix

// before
createStorageFromConfig({ kind: 'datalke', endpoint: 'https://x' })
// after
const SUPPORTED = ['s3', 'datalake', 'hulylake']
if (!SUPPORTED.includes(config.kind)) throw new Error(`bad kind: ${config.kind}`)
createStorageFromConfig({ kind: 'datalake', endpoint: 'https://x' })

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED_KINDS = ['s3', 'datalake', 'hulylake'] // match DATALAKE_CONFIG_KIND / HULYLAKE_CONFIG_KIND
function assertSupportedKind(cfg) {
  if (!SUPPORTED_KINDS.includes(cfg.kind)) {
    throw new Error(`Unsupported storage kind '${cfg.kind}'; expected one of ${SUPPORTED_KINDS.join(', ')}`)
  }
}

Type guard

function isSupportedStorageConfig(c) {
  return typeof c === 'object' && c !== null &&
    ['s3', 'datalake', 'hulylake'].includes(c.kind)
}

Try / catch

try {
  adapter = createStorageFromConfig(cfg)
} catch (e) {
  if (e.message.startsWith('Unsupported storage kind:')) {
    console.error(`Config kind '${cfg.kind}' not supported by this build; check typos or upgrade the server`)
  }
  throw e
}

Prevention

Centralize kind constants and derive config parsing from them instead of free-form strings
Validate kind against the supported list at config load time
When adding a new storage kind, update both the config producers and the starter dispatch together

When it happens

Trigger: Calling createStorageFromConfig with a config whose kind is not one of the supported constants — typo in kind string, kind field absent (kind === undefined), or a kind added by a newer plugin not supported by this server build.

Common situations: Typo like 'datalke' in config; missing kind field entirely; version mismatch where workspace config uses a storage kind the deployed server doesn't know.

Related errors

AI-assisted analysis of hcengineering/platform@63e28dc964 (2026-08-29). Data as JSON: /api/errors/560e53378dfdbcdc. Report an issue: GitHub.