langgenius/dify · error · KnowledgeCreationError

Knowledge creation failed during policy

Error message

Knowledge creation failed during policy

What it means

Wrapped KnowledgeCreationError thrown when the post-creation policy step fails. Stage is 'policy' and crucially the already-created knowledge space is attached as createdKnowledge so callers can recover or clean up. The policy step fetches the access policy and, if visibility differs, PATCHes it to the requested value (e.g. 'all_members').

Source

Thrown at web/features/new-rag/create-knowledge-workflow.ts:86

  try {
    if (values.visibility === 'all_members') {
      const policy = await consoleClient.knowledgeFs.getKnowledgeSpacesByIdAccessPolicy({
        params: { id: created.id },
      })
      if (policy.visibility !== values.visibility) {
        await consoleClient.knowledgeFs.patchKnowledgeSpacesByIdAccessPolicy({
          body: {
            expectedRevision: policy.revision,
            partialMemberSubjectIds: [],
            visibility: values.visibility,
          },
          params: { id: created.id },
        })
      }
    }
  } catch (error) {
    throw new KnowledgeCreationError('policy', error, created)
  }

  return created
}

View on GitHub (pinned to ef8544b173)

Solutions

  1. On retry, pass { existingKnowledge: error.createdKnowledge } so createKnowledge skips the create step and only re-attempts policy.
  2. If the failure is a revision conflict, re-fetch the policy to obtain a fresh revision before patching.
  3. Check error.originalError.status: 403 -> user cannot set all_members visibility; 409 -> revision conflict, refetch.
  4. Warn the user that the knowledge space was created but visibility was not applied.

Example fix

// before
catch (error) {
  throw new KnowledgeCreationError('policy', error, created)
}

// after - recover using the created space on retry
try {
  await createKnowledge(values)
} catch (e) {
  if (e instanceof KnowledgeCreationError && e.stage === 'policy' && e.createdKnowledge) {
    await createKnowledge({ ...values, existingKnowledge: e.createdKnowledge })
  }
}
Defensive patterns

Strategy: retry

Validate before calling

// Retry policy step using already-created space
async function createKnowledgeWithRecovery(values: CreateKnowledgeValues) {
  try {
    return await createKnowledge(values)
  } catch (e) {
    if (e instanceof KnowledgeCreationError && e.stage === 'policy' && e.createdKnowledge) {
      return createKnowledge({ ...values, existingKnowledge: e.createdKnowledge })
    }
    throw e
  }
}

Type guard

function isPolicyStageError(e: unknown): e is KnowledgeCreationError {
  return e instanceof KnowledgeCreationError && e.stage === 'policy' && !!e.createdKnowledge
}

Try / catch

try {
  await createKnowledge(values)
} catch (e) {
  if (e instanceof KnowledgeCreationError && e.stage === 'policy') {
    notify(`Knowledge '${e.createdKnowledge?.name}' created, but visibility could not be applied.`)
  }
}

Prevention

When it happens

Trigger: Fires when getKnowledgeSpacesByIdAccessPolicy or patchKnowledgeSpacesByIdAccessPolicy rejects, or when an optimistic-revision conflict occurs (expectedRevision mismatch). Also fires if values.visibility === 'all_members' and either call fails.

Common situations: Concurrent policy modification caused an expectedRevision conflict, the user lacks permission to change visibility, or the KnowledgeFS gateway had a transient error after the space was already created. The space exists in createdKnowledge and should not be re-created on retry.

Related errors


AI-assisted analysis of langgenius/dify@ef8544b173 (2026-08-12). Data as JSON: /api/errors/a71ea54c03fda54b. Report an issue: GitHub.