cleanup(phase8): move export_collection_task to KB domain (Option β follow-up to #1670)#1672
Merged
Merged
Conversation
…ollow-up) Carve-finishing follow-up to #1670 (task #39): now that ExportTask ORM lives in aperag/domains/knowledge_base/db/models.py, the matching Celery task body can move to the KB domain too. - Move `export_collection_task` + `_build_manifest` from `config/export_tasks.py` to `aperag/domains/knowledge_base/tasks.py`, pinned with `name="config.celery_tasks.export_collection_task"` to match the convention of the other KB-domain tasks. - Update the only caller (`aperag.service.export_service`) to import from the new location. - Drop `config.export_tasks` from `config/celery.py` `include=` list. - Delete `config/export_tasks.py`. - Update KB models docstring to reflect the task body's new home. Pure code move + import path update — no behavior change. Gates green (21/21 boundary, 676 pass / 29 skip / 1 deselect / 0 fail unit suite, ruff clean).
CI lint-and-unit job runs `ruff format --check` (stricter than `ruff check`). My local pre-push gate only ran the latter, missing this. Pure mechanical reformat in the export_collection_task block — no semantic change. Architect canonical LGTM (msg=ca62c787) and Weston no-blocker CR (msg=e91a922c) both still apply since the move scope and task-name pin are unchanged. Note: indexing/tasks.py also flags ruff format check on origin/main itself (pre-existing drift carried in by an earlier merge); that file is outside this PR's move-only scope and not touched here.
earayu
added a commit
that referenced
this pull request
Apr 25, 2026
…) (#1677) * refactor(phase8-g1): carve export v1 shim to knowledge_base domain (#47) Per PM scope (msg=7733c905) and Bryce inventory G1: complete the export carve trail started by #1670 (ExportTask ORM) and #1672 (export_collection_task). Pure carve / move; URL contract `/api/v1/export*` and `/api/v1/export-tasks*` unchanged. Changes: - aperag/views/export.py → aperag/domains/knowledge_base/api/export_routes.py (3 routes: create_export_task / get_export_task / download_export; switched User ORM dep → AuthenticatedUser Protocol, matching the canonical KB routes pattern) - aperag/service/export_service.py → aperag/domains/knowledge_base/service/export_service.py (git mv preserves history; replaced view_models.ExportTaskResponse references with bare ExportTaskResponse imported from KB schemas) - ExportTaskResponse schema migrated from aperag/schema/view_models.py to aperag/domains/knowledge_base/schemas.py (added to __all__); view_models.py keeps a backward-compat re-export following the same pattern used for knowledge_graph/retrieval schemas - aperag/app.py: import switched from aperag.views.export to aperag.domains.knowledge_base.api.export_routes; mount prefix remains /api/v1 (D1 hard-cut to /api/v2 deferred to later G3+ batch) Verification: - pytest tests/unit_test/test_modularization_boundaries.py -x → 21 passed (G1-G19 all green; new KB route does not import legacy aggregates) - pytest tests/unit_test/ → 686 passed, 29 skipped (matches phase8 baseline) - grep "from aperag.service.export_service|from aperag.views.export" returns 0 hits in aperag/, tests/, config/ - python -c "from aperag.app import app; ..." confirms 3 export endpoints remain at /api/v1/collections/{id}/export, /api/v1/export-tasks/{id}, /api/v1/export-tasks/{id}/download aperag/service/ retains exactly the 3 permanent seam files (quota_service / prompt_template_service / search_pipeline_service); no Layer A / Layer B violation. Ghost-check: none. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor(phase8-g1): D7 v2 hard-cut for export endpoints (#47) Per @符炫炜 D7 canonical update (msg=30405f5b) + PM msg=3b0c2589: G1 includes URL prefix migration `/api/v1/export*` → `/api/v2/export*`, not just file carve. - aperag/app.py: export_router mount /api/v1 → /api/v2 - aperag/domains/knowledge_base/api/export_routes.py: docstring updated to reflect D7 v2 hard-cut - aperag/domains/knowledge_base/service/export_service.py: download_url template /api/v1/... → /api/v2/... - web/src/api-v2/schema.d.ts: 3 export route key strings v1 → v2 - web/src/features/collection/client-api.ts: 2 client call paths v1 → v2 - tests/unit_test/test_web_typed_api_contract.py: assertions and comment updated to expect v2 paths post-D7 Verification: - pytest tests/unit_test/test_modularization_boundaries.py tests/unit_test/test_web_typed_api_contract.py -x → 37 passed - python -c "from aperag.app import app; ..." → 3 export endpoints now mounted at /api/v2/{collections/{id}/export, export-tasks/{id}, export-tasks/{id}/download} - grep "/api/v1/export" aperag/ tests/ web/ config/ → 0 hits (a single unrelated historical comment about KG-eval export remains in knowledge_graph/api/routes.py:259, untouched) Ghost-check: none. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
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
1 participant
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.
Summary
Tiny carve-finishing follow-up to #1670 (task #39). Now that
ExportTaskORM lives inaperag/domains/knowledge_base/db/models.py(carved by #1670), the matching Celery task body can finally move to the KB domain too. This was the Option β plan I committed to in the architect's task #39 thread (msg=e8a6f680).Changes (pure code move):
export_collection_task+_build_manifestfromconfig/export_tasks.pytoaperag/domains/knowledge_base/tasks.py, pinned withname=\"config.celery_tasks.export_collection_task\"per architect spec (msg=aa120d85), matching the convention of the other KB-domain tasks (collection_init_task/collection_delete_task/ etc.).aperag.service.export_service) to import from the new location.config.export_tasksfromconfig/celery.pyinclude=list.config/export_tasks.py.Net: -237 / +220 LOC (effectively pure move; the small delta is dropping the stale
from aperag.utils.utils import utc_nowre-import inside_build_manifestsince it's already imported at module top intasks.py).No behavior change. Same task body, same
ExportTaskORM, samedelay()call site.Test plan
uv run python -m pytest tests/unit_test/test_modularization_boundaries.py -x -q→ 21 passed (G1-G19 + new G20+)uv run python -m pytest tests/unit_test -q --deselect 'tests/unit_test/test_web_typed_api_contract.py::test_phase1_fe_complete_identity_auth_admin_audit_adapter_boundary'→ 676 passed / 29 skipped / 1 deselected / 0 faileduv run ruff check aperag/ tests/ config/→ cleangrep -rn 'config.export_tasks\|config/export_tasks\|from config\.export_tasks'→ 0 matches (only caller updated)🤖 Generated with Claude Code