Molunerfinn/PicGo · error

Failed to load provider configs

Error message

Failed to load provider configs

What it means

getProviderConfigList calls the main process via invokeRPC(IRPCActionType.GET_PICBED_CONFIG_LIST) and throws when the RPC result reports failure with no detailed error message. On the main side (src/main/events/rpc/routes/config.ts:40) the handler calls picgo.uploaderConfig.getConfigList(type)/getActiveConfig(type); any exception there is caught and returned as a failed RPC envelope, which the renderer converts into this error. It means the uploader/picbed config list for the given type could not be read from the persisted PicGo config.

Source

Thrown at src/renderer/adapters/providers.ts:23

import { ipc } from '@/utils/bridge'

export interface ProviderSchemaResult {
  config: IPicGoPluginConfig[]
  name: string
}

export const providersAdapter = {
  async changeCurrentUploader (type: string, configName?: string) {
    const result = await invokeRPC<string>(IRPCActionType.CHANGE_CURRENT_UPLOADER, type, configName)
    if (!result.success) {
      throw new Error(result.error || 'Failed to change current uploader')
    }
    return result.data
  },
  async getProviderConfigList (type: string) {
    const result = await invokeRPC<IUploaderConfigItem>(IRPCActionType.GET_PICBED_CONFIG_LIST, type)
    if (!result.success) {
      throw new Error(result.error || 'Failed to load provider configs')
    }

    return result.data
  },
  async selectProviderConfig (type: string, configName: string) {
    const result = await invokeRPC<string>(IRPCActionType.SELECT_UPLOADER, type, configName)
    if (!result.success) {
      throw new Error(result.error || 'Failed to select provider config')
    }

    return result.data
  },
  async deleteProviderConfig (type: string, configName: string) {
    const result = await invokeRPC<IUploaderConfigItem>(IRPCActionType.DELETE_PICBED_CONFIG, type, configName)
    if (!result.success) {
      throw new Error(result.error || 'Failed to delete provider config')
    }

View on GitHub (pinned to 07ec7068a5)

Solutions

  1. Check the main-process logs for the underlying exception thrown by picgo.uploaderConfig.getConfigList and fix that root cause
  2. Validate/repair the PicGo config file (backup, then remove or fix the corrupted uploader section)
  3. Pass a valid registered uploader type (e.g. 'smms', 'aliyun') rather than an arbitrary string
  4. Retry after reloading the settings window so the renderer re-syncs with the main process

Example fix

// before
const list = await getProviderConfigList(unknownType)
// after
if (!type || typeof type !== 'string') throw new Error('uploader type is required')
const list = await getProviderConfigList(type)
Defensive patterns

Strategy: try-catch

Validate before calling

if (typeof type !== 'string' || !type.trim()) throw new Error('uploader type is required')

Type guard

function isValidType(t: unknown): t is string { return typeof t === 'string' && t.trim().length > 0 }

Try / catch

let configList
try {
  configList = await getProviderConfigList(type)
} catch (e) {
  logger.error('[picbed] failed to load config list', e)
  showNotification($T('TIPS_LOAD_CONFIG_FAILED'))
  configList = { configList: [], defaultId: '' } // graceful fallback
}

Prevention

When it happens

Trigger: Calling providersAdapter.getProviderConfigList(type) when the main-process handler throws (e.g. picgo config file unreadable/corrupt so uploaderConfig access fails), or when result.success is false with an empty error string so only the fallback message is shown.

Common situations: PicGo config file corrupted or locked, uploader type string that has no registered config entries, main process state not fully initialized after an update/migration, or a stale renderer talking to a restarted main process.

Related errors


AI-assisted analysis of Molunerfinn/PicGo@07ec7068a5 (2026-08-30). Data as JSON: /api/errors/123edad2762e7505. Report an issue: GitHub.