Что означает код HRESULT 0x80630011 (PEER_E_DBNAME_CHANGED)?

 
Предыдущий Следующий
PEER_E_INVALID_GRAPH PEER_E_DUPLICATE_GRAPH

PEER_E_DBNAME_CHANGED

PEER_E_DBNAME_CHANGED — HRESULT 0x80630011 означает, что один и тот же граф открыт в процессе с именем базы, отличающимся от имени, использованного при первом открытии. PEER_E_DBNAME_CHANGED — Исследуйте первый API, сообщивший этот результат, а не более поздний UI wrapper.

Вопросы, отделяющие этот сбой

  • Объект был получен через PeerGraphOpen и код приложения, формирующий имя базы графа, либо восстановлен из кэшированного текста или другого процесса?
  • Сохраните graph ID, peer ID, оба имени базы и нормализованные пути, порядок вызовов открытия, время жизни процесса и источник конфигурации каждого имени.
  • Произошли ли shutdown, deletion, sign-out, expiration или replication между выбором объекта и его использованием?
  • Завершается ли операция успешно при контролируемом сравнении, описанном ниже?

Peer Graphing поддерживает связанный набор nodes, реплицирует records и имеет отдельные lifetimes graph, node, connection и event. Открытая graph database не означает, что node подключён.

Контролируемое сравнение

дважды откройте граф в одном тестовом процессе с исходным именем базы, затем измените только второе имя для воспроизведения несоответствия. Сохраняйте identity, graph/group ID, cloud и user context неизменными, если только один из них не является проверяемой переменной.

Таблица решений

Наблюдаемый результатСледующее действие для PEER_E_DBNAME_CHANGED
HRESULT повторяется при идентичном зафиксированном состоянииПроверьте контракт вызывающего кода и состояние node/connection; повторные сетевые попытки не добавят доказательств.
Вызов продвигается до PEER_E_DUPLICATE_GRAPHPEER_E_DUPLICATE_GRAPH отличается тем, что duplicate-graph относится к повторному использованию graph ID при создании, а database-name-changed — к несогласованной конфигурации открытия.
Контролируемый запуск успешен, production — нетСравните user token, database path, cloud, endpoint, certificate chain и фактическую firewall policy.

Безопасное исправление и проверка

используйте одно стабильное имя базы для каждого графа внутри процесса, а перенос или импорт выполняйте только при закрытом графе. Перед изменениями создайте резервные копии экспортируемой identity и group configuration и сохраните hashes database/invitation artifacts.

Исправление подтверждено только когда нужная операция успешна, а полученные соединения, записи, членство, endpoint или область Peer Collaboration можно независимо перечислить.

Инструментирование и регрессионное покрытие

Фиксируйте первый неудачный вызов, а не более поздний результат cleanup. Решающее значение имеют graph ID, peer ID, оба имени базы и нормализованные пути, порядок вызовов открытия, время жизни процесса и источник конфигурации каждого имени.

Регрессионный уровеньПроверяемый случайУсловие прохождения
Входные данные и время жизни объектаПостройте минимальный сценарий, в котором один граф открывается в процессе с именем базы, отличающимся от использованного при первом открытии.В тесте фиксируются владеющий дескриптор, контекст пользователя и точный API из PeerGraphOpen и кода приложения, формирующего имя базы графа.
Контролируемое сравнениедважды откройте граф в одном тестовом процессе с исходным именем базы, затем измените только второе имя для воспроизведения несоответствия.Между неуспешным и успешным запуском изменяется только целевое состояние node или connection.
Путь восстановленияиспользуйте одно стабильное имя базы для каждого графа внутри процесса, а перенос или импорт выполняйте только при закрытом графе.Нужная операция завершается успешно без замены несвязанной replicated graph database.

Сохраняйте unsigned hexadecimal HRESULT, symbolic names и timestamps в одной трассировка. Такая запись позволяет регрессионному тесту отличить состояние жизненного цикла графа от последующего сбоя транспорта, авторизации или приложения.

Ссылки


Нужно найти другой код? Найти другой код состояния или ошибки.