-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: [ingest-file]: database-related errors when processing PDF files #4002
Comments
Noting that we are also getting this error in version |
Relates to #3872 and tagging @stchris as per the request in the comment here #3872 (comment) |
ingest-file uses the Tags functionality from servicelayer to cache certain document types during ingest to speed up its operation. Normally the settings file defaults to trying the ALEPH_DATABASE_URI followed by the FTM_STORE_URI, which in most cases should be set to non-default values. But if one were to just follow our prod environment docs blindly and not uncomment these two settings then the TAGS_DATABASE_URI would be unset, causing servicelayer to pick the default (sqlite:///) which breaks now that we have multiple threads writing to the tags database. This change documents how this setting works and encourages one to set it if the above two settings are left to defaults. Relates to #4002, #3816
Looking at the setup everyone who is reporting this issue the one common thing is following a typical environment setup (little or no changes to Long story short, to fix this issue:
OR
|
ingest-file uses the Tags functionality from servicelayer to cache certain document types during ingest to speed up its operation. Normally the settings file defaults to trying the ALEPH_DATABASE_URI followed by the FTM_STORE_URI, which in most cases should be set to non-default values. But if one were to just follow our prod environment docs blindly and not uncomment these two settings then the TAGS_DATABASE_URI would be unset, causing servicelayer to pick the default (sqlite:///) which breaks now that we have multiple threads writing to the tags database. This change documents how this setting works and encourages one to set it if the above two settings are left to defaults. Relates to #4002, #3816
I can confirm that it works for my instance. Thanks for that ! |
Describe the bug
docker compose logs ingest-file
shows errors likeHuman-readable backtrace:
Human-readable backtrace:
To Reproduce
docker-compose.yml
andaleph.env.tmpl
, configurealpeh.env
docker compose run --rm shell aleph upgrade
docker compose up -d
docker compose logs -f
in a terminal and watch.Expected behavior
Documents are processed without any errors, and I can see their content in the UI.
Aleph version
4.0.1
Screenshots

Additional context

"no such table: ingest_cache" is not a new error, it also happens in the stable 3.17.0 branch:
Related: #3816; I use the default
ALEPH_DATABASE_URI
The text was updated successfully, but these errors were encountered: