refactor(BA-5979): split deployment search into admin and scoped layers#11522
Draft
jopemachine wants to merge 8 commits intomainfrom
Draft
refactor(BA-5979): split deployment search into admin and scoped layers#11522jopemachine wants to merge 8 commits intomainfrom
jopemachine wants to merge 8 commits intomainfrom
Conversation
Move ``search_model_deployments`` (no-scope, returns ``ModelDeploymentData`` directly from ``EndpointRow``) into a dedicated ``DeploymentAdminRepository`` and route it through a new ``DeploymentAdminService`` / ``DeploymentAdminProcessors`` package. The corresponding action is renamed to ``AdminSearchDeploymentsAction`` so its admin (no-scope) intent is explicit at every layer, mirroring the ``vfolder`` / ``login_client_type`` admin-split convention. The five service paths that previously called ``_convert_deployment_info_to_data`` on a freshly fetched ``DeploymentInfo`` (``create_deployment``, ``update_deployment``, ``get_deployment_by_id``, ``activate_revision``, plus the search path) now read straight from ``EndpointRow.to_model_deployment_data`` via the repository, so revision-id columns flow through the API path unchanged from the DB and the ``model_revisions`` ordering ambiguity that BA-5963 patched out becomes unreachable structurally. The legacy REST handler and the v2 GraphQL adapter both consume the new ``deployment_admin`` processor; the orphaned ``SearchDeploymentsAction`` file is removed. ``DeploymentAdminRepository`` shares the underlying ``DeploymentDBSource``, so SQL-level query logic stays in one place — only the layering above it is split. Resolves BA-5979.
github-actions
Bot
added
comp:manager
…mentsAction Walks back the over-eager rewiring from the previous BA-5979 commit: - Restore ``_convert_deployment_info_to_data`` (and its ``_map_lifecycle_to_status`` helper) on ``DeploymentService`` for the legacy projection path. - Rename the action to ``SearchLegacyDeploymentsAction`` (file ``services/deployment/actions/search_legacy_deployments.py``) so the legacy intent is explicit; keep the original ``search_endpoints`` -> ``DeploymentInfo`` -> converter -> ``ModelDeploymentData`` pipeline intact in the service handler. - Adapter ``my_search`` / ``project_search`` and the GraphQL ``batch_load_by_ids`` go back to the regular processor's ``search_legacy_deployments``; only ``admin_search`` stays on the new ``DeploymentAdminProcessors.admin_search_deployments``. - The legacy v1 REST handler and ``tree.py`` are reverted to ``origin/main`` except for the import / call-name update forced by the action rename. - Drop the now-unused ``search_model_deployments`` helper from ``DeploymentRepository`` so the no-scope query is owned by ``DeploymentAdminRepository`` alone.
…he model layer The previous commit attached ``to_model_deployment_data`` and the ``_lifecycle_to_status`` helper to ``EndpointRow``, but the conversion is purely an adapter between the ORM row and the API-shaped data type — that is not a model-layer concern. Move both into ``repositories/deployment/db_source/db_source.py`` as private free functions (``_endpoint_row_to_model_deployment_data`` and ``_lifecycle_to_status``); ``get_model_deployment_data`` and ``search_model_deployments`` now call the helper directly. The companion unit test moves to ``tests/unit/manager/repositories/deployment/test_endpoint_projection.py`` to match the new home, and the component test reverts to importing ``_map_lifecycle_to_status`` from ``services/deployment/service.py`` (its origin/main location).
jopemachine
commented
May 8, 2026
| log = BraceStyleAdapter(logging.getLogger(__name__)) | ||
|
|
||
|
|
||
| def _lifecycle_to_status(lifecycle: EndpointLifecycle) -> ModelDeploymentStatus: |
Member
Author
There was a problem hiding this comment.
I think this should be included adapter
Following the vfolder convention so v2 paths no longer borrow the
``search_legacy_deployments`` action.
- Add ``UserDeploymentSearchScope`` (alongside the existing
``ProjectDeploymentSearchScope``) so the user-scope filter
(``EndpointRow.created_user == user_id``) lives at the repository
boundary instead of being injected at the adapter via
``base_conditions``.
- Add ``SearchUserDeploymentsAction`` and ``SearchProjectDeploymentsAction``
(returning ``ModelDeploymentData``) plus matching service handlers,
processor fields, and repository / DB-source methods. The internal
scope-name is ``User``; the v2 adapter exposes it as ``my_search``.
- Adapter:
- ``my_search`` -> ``search_user_deployments``
- ``project_search`` -> ``search_project_deployments``
- ``batch_load_by_ids`` (DataLoader) -> ``admin_search_deployments`` —
the ``by_ids`` filter is itself the bound on the result set, so the
no-scope admin processor is the right home; this also keeps
``search_legacy_deployments`` reserved for the v1 REST handler.
The existing ``SearchDeploymentsInProjectAction`` (returning
``DeploymentSummaryData``) is unchanged — its lighter shape is still
what project admin list pages consume.
…egacy_deployments Going through ``DeploymentAdminProcessors.admin_search_deployments`` made the DataLoader path admin-only, which breaks any non-admin GraphQL query that resolves a deployment reference (e.g. ``ModelDeploymentNode`` from a sibling entity). The admin processor exists to mark callers that *must* be admin-authorised; a DataLoader inherits the parent resolver's authorisation and runs for every user, so it cannot live there. Route ``batch_load_by_ids`` through the regular ``DeploymentProcessors.search_legacy_deployments`` until a dedicated non-admin batch action lands (the action's ``legacy`` name is awkward for a v2 DataLoader path; renaming is left to a follow-up so the v1 REST contract stays untouched in this PR).
The dependency was held on the DB source but never read by any of its methods — storage I/O lives on ``DeploymentStorageSource`` (still owned by ``DeploymentRepository``). Drop the field, the ctor parameter, and the forwarding through both repositories.
…ployments` consistently
The admin repo had `search_model_deployments`, but the new user/project
counterparts and matching actions/handlers/processors used the shorter
`deployments`. Align them: methods, actions, handlers, processor fields,
and action file names that return `ModelDeploymentData` now all read
`*_model_deployments` / `*ModelDeployments*`. The legacy
`search_legacy_deployments` (returns `ModelDeploymentData` via the
`DeploymentInfo` converter) keeps its name to preserve the v1 REST
contract surface, and `*DeploymentSearchScope` keeps its name because
the scope describes the entity being filtered, not the return type.
Renames:
- AdminSearchDeploymentsAction -> AdminSearchModelDeploymentsAction
- SearchUserDeploymentsAction -> SearchUserModelDeploymentsAction
- SearchProjectDeploymentsAction -> SearchProjectModelDeploymentsAction
- service.{admin_search,search_user,search_project}_deployments -> *_model_deployments
- processor fields and action file paths follow.
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
Split the deployment search/projection paths so each axis (admin / user / project / legacy / DataLoader) has a dedicated action and repository method.
create/update/get/activate_revisionreads throughEndpointRow->ModelDeploymentDatadirectly via the private helper_endpoint_row_to_model_deployment_dataat thedb_source/boundary.DeploymentAdminRepository+DeploymentAdminService+DeploymentAdminProcessorspackage, mirroring thevfolder/login_client_typeadmin-split convention.my_search) and project-scoped (project_search) reads each get their ownSearch{User,Project}ModelDeploymentsAction+*DeploymentSearchScope; the scope filter lives in the repository, not on the adapter as an injectedbase_condition.ModelDeploymentDatareads*_model_deployments/*ModelDeployments*, matching the entity term carried by the data type (parallel tosearch_vfolders<-VFolderData). Scope class names keep*DeploymentSearchScopebecause the scope describes the entity being filtered, not the return type.SearchLegacyDeploymentsAction(renamed fromSearchDeploymentsAction) and continues to project viaDeploymentInfo->_convert_deployment_info_to_data->ModelDeploymentData.batch_load_by_ids) sharesSearchLegacyDeploymentsActionfor now; the admin processor was a wrong fit because DataLoader fires under the parent resolver's user (admin or not). Renaming the shared action so it does not read aslegacyfor the v2 DataLoader path is left to a follow-up.Resolves BA-5979. Builds on top of #11494 (BA-5963) which is already on
main.Layer-by-layer changes
Models
models/endpoint/row.pyto_deployment_infoonlyRepository
DeploymentRepositoryget_endpoint_infoDeploymentInfoDeploymentRepositoryget_model_deployment_dataModelDeploymentDatafor the API pathDeploymentRepositorysearch_endpointsDeploymentInfoDeploymentRepositorysearch_user_model_deploymentsModelDeploymentDataDeploymentRepositorysearch_project_model_deploymentsModelDeploymentDataDeploymentRepositorysearch_deployments_in_projectDeploymentSummaryDataDeploymentAdminRepositorysearch_model_deploymentsModelDeploymentDatarepositories/deployment/db_source/db_source.py(helper functions)_lifecycle_to_status_endpoint_row_to_model_deployment_dataEndpointRowstraight toModelDeploymentData; called by every new ModelDeploymentData-returning DB-source methodDeploymentDBSource._storage_managerDeploymentStorageSource(still owned byDeploymentRepository)Scopes
ProjectDeploymentSearchScopeUserDeploymentSearchScopeEndpointRow.created_user == user_idAction
SearchDeploymentsActionSearchLegacyDeploymentsAction(fileactions/search_legacy_deployments.py); now serves the v1 REST handler and the v2 GraphQL DataLoaderAdminSearchModelDeploymentsActionSearchUserModelDeploymentsActionSearchProjectModelDeploymentsActionModelDeploymentDataSearchDeploymentsInProjectActionDeploymentSummaryDataService
DeploymentServicecreate_deploymentget_endpoint_info+_convert_deployment_info_to_dataget_model_deployment_dataDeploymentServiceupdate_deploymentDeploymentInfo-> convertget_model_deployment_dataDeploymentServiceget_deployment_by_idget_endpoint_info+ convertget_model_deployment_dataDeploymentServiceactivate_revisionDeploymentInfo-> convertget_model_deployment_dataDeploymentServicesearch_deployments->search_legacy_deploymentssearch_endpoints+_convert_deployment_info_to_dataDeploymentServicesearch_user_model_deploymentsDeploymentServicesearch_project_model_deploymentsModelDeploymentDataDeploymentAdminServiceadmin_search_model_deploymentsDeploymentAdminRepository.search_model_deploymentsProcessor
DeploymentProcessorssearch_deploymentssearch_legacy_deploymentsDeploymentProcessorssearch_user_model_deploymentsDeploymentProcessorssearch_project_model_deploymentsDeploymentAdminProcessors(new)admin_search_model_deploymentsProcessorsAdapter routing
admin_searchSearchDeploymentsAction(regular processor)AdminSearchModelDeploymentsAction(admin processor)my_searchSearchDeploymentsAction+created_user==user_idbase-conditionSearchUserModelDeploymentsAction+UserDeploymentSearchScope(regular processor)project_searchSearchDeploymentsAction+project==project_idbase-conditionSearchProjectModelDeploymentsAction+ProjectDeploymentSearchScope(regular processor)batch_load_by_ids(DataLoader)SearchDeploymentsAction+by_idsconditionSearchLegacyDeploymentsAction+by_idscondition (regular processor — admin processor is admin-only and DataLoader fires for every user)Legacy v1 REST handler
api/rest/deployment/handler.pywait_for_completereference are renamed (SearchDeploymentsAction->SearchLegacyDeploymentsAction); logic untouchedapi/rest/tree.pyorigin/mainService-layer helpers (legacy converter)
_map_lifecycle_to_status(service.py)_convert_deployment_info_to_data(service.py)search_legacy_deploymentsKnown limitation / follow-up
SearchLegacyDeploymentsActionis shared between the v1 REST handler and the v2 GraphQL DataLoader. The action's name reads aslegacy, which is accurate for the v1 REST consumer but not for the DataLoader path — splitting it (e.g. into a dedicatedBatchLoadDeploymentsByIdsAction) is intentionally deferred so this PR does not touch the v1 REST contract surface.Test plan
pants fmt fix lint checkon every changed filetests/unit/manager/repositories/deployment/test_endpoint_projection.py— new unit test for_endpoint_row_to_model_deployment_datacovering reversedrevisionsorder, danglingcurrent_revisionreferences, and the lifecycle status mapping./baismoke after merge: admin search, my search, project search, GraphQLmodelDeploymentresolver (DataLoader), legacysearch_deploymentsREST endpoint🤖 Generated with Claude Code