bulkload-db: retry chunk uploads and fail loud on incomplete loads#24
Merged
Conversation
bulkload_duckdb silently swallowed per-chunk upload failures: a chunk that timed out (or returned 5xx) yielded 0 and the load still reported success with a short document count. In a Monarch KG release build this shipped a Solr entity core with ~half its documents while the job exited 0. - _upload_docs_to_solr retries transient failures (timeouts, connection resets, 5xx) with exponential backoff. Re-POSTing is idempotent because each doc has a unique id, so a retry overwrites rather than duplicates -- safe even when a prior attempt timed out client-side but Solr had already indexed the batch. - After exhausting retries it raises instead of returning 0. - bulkload_duckdb tracks failed chunks and raises unless total_loaded == total_rows; the outer handler re-raises rather than returning 0, so the CLI exits non-zero on any incomplete load.
kevinschaper
added a commit
that referenced
this pull request
Jun 9, 2026
The version field was never advanced past 0.2.0, so even with a working publish workflow a release would build 0.2.0 and collide with the existing PyPI file. Set it to 0.2.3 (next free version; 0.2.1/0.2.2 tags exist but never published) so the release carries the loader fix (#24) and the publish-workflow fix.
kevinschaper
added a commit
that referenced
this pull request
Jun 9, 2026
…release (#25) * ci(pypi-publish): bump Python to 3.11 and modernize actions The publish job pinned Python 3.8 and let snok/install-poetry pull the latest Poetry, which is now 2.4.1 and dropped Python 3.8 support -- so 'Install Poetry' failed before building, and v0.2.1 and v0.2.2 never reached PyPI. Bump to Python 3.11 and refresh the deprecated actions (checkout v2->v4, setup-python v2->v5, gh-action-pypi-publish v1.2.2->release/v1). * bump version to 0.2.3 for release The version field was never advanced past 0.2.0, so even with a working publish workflow a release would build 0.2.0 and collide with the existing PyPI file. Set it to 0.2.3 (next free version; 0.2.1/0.2.2 tags exist but never published) so the release carries the loader fix (#24) and the publish-workflow fix.
kevinschaper
added a commit
to monarch-initiative/monarch-ingest
that referenced
this pull request
Jun 9, 2026
Pulls in the retry + fail-loud bulkload fix (linkml/linkml-solr#24, released in 0.2.3). uv.lock entry updated surgically — 0.2.3's dependency set is identical to 0.2.0 (the release only changed loader internals, the publish workflow, and the version), so a full re-resolve wasn't needed (and is currently blocked by an unrelated koza[grape]/ensmallen pin).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
bulkload_duckdbsilently swallowed per-chunk upload failures. A chunk that timed out (or returned a 5xx) was caught, logged, and counted as0— but the load still finished and reported success with a short document count. The CLI then printedSuccessfully committed <N> documentsand exited0.In a Monarch KG release build this shipped a Solr entity core with only ~728k of ~1.46M documents (and the association core similarly short) while the Jenkins job passed as SUCCESS. The downstream symptom was
get_entity()returningNonefor genes/diseases that were present in the same release's graph — because their chunk had timed out during indexing and was never retried or flagged.Root cause in the logs:
Fix
_upload_docs_to_solr: retries transient failures (timeouts, connection resets, 5xx) with exponential backoff. Re-POSTing a chunk is idempotent because every doc carries a uniqueid, so a retry overwrites rather than duplicates — safe even when a prior attempt timed out client-side but Solr had already indexed the batch. After exhausting retries it raises instead of returning0.bulkload_duckdb: tracks failed chunks and raises unlesstotal_loaded == total_rows; the outer handler re-raises rather than returning0, so the CLI exits non-zero on any incomplete load.Validation
Against a local Solr with the patched loader:
RuntimeError: Incomplete Solr load ... uploaded 0/172,957 rows ... Refusing to report success, exit 1.Builds on the streaming
bulkload_duckdbalready onmain(#22 / 1a9195a).