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

  1. Verify the collector/Python service is running and its HTTP port matches the server's COLLECTOR_API configuration.
  2. Hit the collector's health/types endpoint directly to confirm it returns a non-empty payload.
  3. Restart the collector container and retry the AnythingLLM endpoint.
  4. Align collector and server versions if there is version skew.
  5. 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

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


AI-assisted analysis of Mintplex-Labs/anything-llm@526360e320 (2026-08-13). Data as JSON: /api/errors/8802e104cc1871f7. Report an issue: GitHub.