Mintplex-Labs/anything-llm · warning
Not Found
Error message
Not Found
What it means
HTTP 404 returned by GET /v1/document/accepted-file-types in AnythingLLM. The handler asks the collector for its supported types via new CollectorApi().acceptedFileTypes(); if the call returns a falsy value (null/undefined/empty) the route answers sendStatus(404). This is not a 'document not found' - it means the collector reported no types.
Source
Thrown at server/endpoints/api/document/index.js:778
".txt",
".md"
]
}
}
}
}
}
}
#swagger.responses[403] = {
schema: {
"$ref": "#/definitions/InvalidAPIKey"
}
}
*/
try {
const types = await new CollectorApi().acceptedFileTypes();
if (!types) {
response.sendStatus(404).end();
return;
}
response.status(200).json({ types });
} catch (e) {
console.error(e.message, e);
response.sendStatus(500).end();
}
}
);
app.get(
"/v1/document/metadata-schema",
[validApiKey],
async (_, response) => {
/*
#swagger.tags = ['Documents']
#swagger.description = 'Get the known available metadata schema for when doing a raw-text upload and the acceptable type of value for each key.'View on GitHub (pinned to 526360e320)
Solutions
- Verify the collector/Python service is running and its HTTP port matches the server's COLLECTOR_API configuration.
- Hit the collector's health/types endpoint directly to confirm it returns a non-empty payload.
- Restart the collector container and retry the AnythingLLM endpoint.
- Align collector and server versions if there is version skew.
- If the collector intentionally returns no types, fix its MIME/config so it advertises at least one accepted type.
Example fix
// before
const r = await fetch('/v1/document/accepted-file-types');
if (r.status === 404) throw new Error('not found');
// after - treat 404 here as 'collector down', not a missing resource
const r = await fetch('/v1/document/accepted-file-types');
if (r.status === 404) throw new Error('Collector returned no file types - check collector service health'); Defensive patterns
Strategy: fallback
Validate before calling
// Probe collector health indirectly before relying on file-types
const r = await fetch('/v1/document/accepted-file-types');
if (r.status === 404) throw new Error('Collector returned no types - verify collector service is up'); Type guard
function isFileTypesPayload(v) {
return v != null && typeof v === 'object' && Array.isArray(v.types) && v.types.length > 0;
} Try / catch
try {
const r = await fetch('/v1/document/accepted-file-types');
if (r.status === 404) throw new Error('no types - collector down or empty config');
if (!r.ok) throw new Error('file-types request failed: ' + r.status);
const json = await r.json();
if (!isFileTypesPayload(json)) throw new Error('empty/invalid types payload');
} catch (e) { throw e; } Prevention
- Treat a 404 from this endpoint as 'collector reported no types', not a missing document.
- Ensure the collector service is running and version-aligned with the server.
- Cache the file-types list at startup to avoid repeated dependency on collector uptime.
- Alert if the endpoint flips from 200 to 404 - it signals collector regression.
When it happens
Trigger: Collector process not running or unreachable so acceptedFileTypes resolves to null; collector running an old version that does not implement the types endpoint; collector connected but returned an empty list due to a config error.
Common situations: Fresh install where the collector container was not started; misconfigured COLLECTOR_API base URL/port; collector crashed and its HTTP server is down; version skew between server and collector where the types route does not exist yet.
Related errors
- Audio conversion failed.
- URL could not be scraped and no content was found.
- URL could not be scraped and no content was found.
- There was no content to be collected or read.
- Failed to transcribe audio.
AI-assisted analysis of Mintplex-Labs/anything-llm@526360e320 (2026-08-13).
Data as JSON: /api/errors/8802e104cc1871f7.
Report an issue: GitHub.