发布

  • [OPIK-5941] [SDK] fix: raise ConfigMismatch when prompt belongs to different project than config (#6296)

    frostbyte_neo 发布于 2026-04-16 09:31:07 +00:00

    • [OPIK-5941] [SDK] fix: raise ConfigMismatch when prompt belongs to different project than config

    When a Prompt or ChatPrompt instance whose project_name differs from the
    config's project is used as a field value, both create_config and
    get_or_create_config (auto-create path) now raise ConfigMismatch immediately
    instead of silently falling back.

    Python:

    • Added _validate_prompt_project_names() to agent_config/base.py, called
      from _create_from_instance (create_config) and _create_from_fallback
      (get_or_create_config auto-create path).

    TypeScript:

    • Added projectName field to BasePromptData / BasePrompt and threaded it
      through Prompt.fromApiResponse, ChatPrompt.fromApiResponse, and the
      createPrompt / createChatPrompt factories.
    • Added validation in Client.createConfig and Client._resolveNullBlueprint
      (get_or_create_config auto-create path).

    Tests (Python + TypeScript): unit tests cover both create_config and
    get_or_create_config for same-project, different-project, and no-project-name cases.

    Implements OPIK-5941

    • [OPIK-5941] [SDK] fix: populate projectName on all prompt retrieval paths

    getPrompt, getChatPrompt, and searchPrompts now pass resolvedProjectName
    (getPrompt/getChatPrompt) or this.resolveProjectName() (searchPrompts) into
    fromApiResponse, so every returned Prompt/ChatPrompt instance carries its
    project name. The guard in createConfig and getOrCreateConfig can now reliably
    fire for prompts obtained via any retrieval method.

    Also extracts the inline validation loop into a shared _validatePromptProjects()
    helper to avoid duplicating the logic across createConfig and _resolveNullBlueprint.

    • [OPIK-5941] [SDK] test: pass project_name when creating prompts in e2e test

    create_prompt/create_chat_prompt with no project_name resolved to the client's
    default project, which differed from the config's explicit project_name —
    now caught by the cross-project guard introduced in this fix.

    下载附件