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
- On retry, pass { existingKnowledge: error.createdKnowledge } so createKnowledge skips the create step and only re-attempts policy.
- If the failure is a revision conflict, re-fetch the policy to obtain a fresh revision before patching.
- Check error.originalError.status: 403 -> user cannot set all_members visibility; 409 -> revision conflict, refetch.
- 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
- On policy-stage retry, always pass existingKnowledge to avoid duplicate space creation.
- Re-fetch the access policy for a fresh revision before patching on conflict.
- Warn the user that the space exists even if visibility failed.
- Idempotently retry only the policy step, not creation.
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
- Knowledge creation failed during create
- deployFailed
- Missing required deployment binding.
- Missing required deployment environment variable.
- unsupportedDslMode
AI-assisted analysis of langgenius/dify@ef8544b173 (2026-08-12).
Data as JSON: /api/errors/a71ea54c03fda54b.
Report an issue: GitHub.