Description of the Bug
The server process aborts when a library scan runs a custom visit that regenerates metadata. A custom visit is the scan mode that only rebuilds selected parts of a book instead of the whole record. The panic comes from sea-orm. The process exits, so the HTTP server stops and the web app shows a 503 error.
The cause is in handle_book_visit_operation in core/src/filesystem/scanner/utils.rs. The metadata branch builds a media_metadata::ActiveModel, sets only media_id, and then calls ActiveModel::update():
let active_model = media_metadata::ActiveModel {
media_id: Set(Some(custom.id.clone())),
..meta.into_active_model()
};
let updated_meta = active_model.update(&txn).await?;The primary key of media_metadata is a different column:
#[sea_orm(primary_key, auto_increment = true)]
pub id: i32,
The value in meta comes from ProcessedMediaMetadata, which the scanner builds from the file on disk. That value carries no database id. sea-orm requires the primary key for ActiveModel::update(), so it panics at update.rs:99.
The panic runs on the main thread and nothing catches it. The result is a full process abort, not a failed job.
The other two scan paths do not have this problem:
- The hash branch of the same function uses
update_many() with an explicit filter. That call does not need the primary key.
- The force rebuild path goes through
update_media(), which writes the metadata with insert().on_conflict().
Expected Behavior
The scan updates the metadata rows and finishes. If the update fails, the job records the error and the server keeps running.
Steps To Reproduce
- Open the settings page of a library that already contains books.
- Click
Configure scan.
- Turn on the option that regenerates metadata.
- Start the scan.
- The server process exits about one second later. The web app shows
Request failed with status code 503.
A process manager can restart the server, but every new scan with the same option stops it again. A scan with only the hash option enabled completes without a problem, which matches the code paths above.
Where is this issue happening?
Server & Client Details
Server Details:
- Release Channel: latest
- Server OS: openSUSE MicroOS
- Using Docker: Yes, on Kubernetes, image
aaronleopold/stump:0.1.7
- Server Version: 0.1.7
Client Details:
- Device: PC
- OS: Linux
- Browser: Not Applicable. The server exits before it answers, so every client sees the same 503.
Additional context
Server log for one occurrence:
2026-09-10T14:49:49.038844Z INFO stump_core::job::run: Starting job, job_id: 4203f1ff-93b4-4b86-b6ab-4b14b0448d61, job_name: "library_scan"
at core/src/job/run.rs:96
thread 'main' (1) panicked at /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/sea-orm-1.1.16/src/query/update.rs:99:40:
PrimaryKey is not set
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The container exited with code 139 and the orchestrator restarted it.
The same code is present on main at the time of this report.
Description of the Bug
The server process aborts when a library scan runs a custom visit that regenerates metadata. A custom visit is the scan mode that only rebuilds selected parts of a book instead of the whole record. The panic comes from sea-orm. The process exits, so the HTTP server stops and the web app shows a 503 error.
The cause is in
handle_book_visit_operationincore/src/filesystem/scanner/utils.rs. The metadata branch builds amedia_metadata::ActiveModel, sets onlymedia_id, and then callsActiveModel::update():The primary key of
media_metadatais a different column:The value in
metacomes fromProcessedMediaMetadata, which the scanner builds from the file on disk. That value carries no databaseid. sea-orm requires the primary key forActiveModel::update(), so it panics atupdate.rs:99.The panic runs on the main thread and nothing catches it. The result is a full process abort, not a failed job.
The other two scan paths do not have this problem:
update_many()with an explicit filter. That call does not need the primary key.update_media(), which writes the metadata withinsert().on_conflict().Expected Behavior
The scan updates the metadata rows and finishes. If the update fails, the job records the error and the server keeps running.
Steps To Reproduce
Configure scan.Request failed with status code 503.A process manager can restart the server, but every new scan with the same option stops it again. A scan with only the hash option enabled completes without a problem, which matches the code paths above.
Where is this issue happening?
Server & Client Details
Server Details:
aaronleopold/stump:0.1.7Client Details:
Additional context
Server log for one occurrence:
The container exited with code 139 and the orchestrator restarted it.
The same code is present on
mainat the time of this report.