What happens
The VWS endpoints are implemented twice:
src/mock_vws/_requests_mock_server/mock_web_services_api.py — 1068 linessrc/mock_vws/_flask_server/vws.py — 1016 lines
The same roughly fifteen endpoints appear in both. The bodies are frequently identical. database_summary is representative: the response dict, the header dict and the email.utils.formatdate call match line for line between mock_web_services_api.py:628 and vws.py:707, differing only in how the request is read and how the response is built.
The Query API is split the same way between _requests_mock_server/mock_web_query_api.py and _flask_server/vwq.py.
Why it matters
The duplication is already causing the two backends to drift. These are supported in-process but not in Flask or Docker, and each is recorded in differences-to-vws.rst as a limitation rather than implemented:
cloud_query_failure_responsemodel_target_generation_failuremodel_target_generation_warningvumark_generation_failuresleep_fn and the response-delay timeout behaviour
Every new feature now costs two implementations or one implementation and one documented gap. Bugs follow the same pattern: #3368 exists only because the Flask backend does its routing and validation differently from the in-process one.
Suggested resolution
Extend the extraction which is already in place rather than inventing a new structure.
src/mock_vws/_model_target_web_api.py and src/mock_vws/_reco_counts_web_api.py are already backend-agnostic: they take a RequestData and return a (status, headers, body) tuple, and both backends call them. The adapters exist too — _flask_request_data and _to_flask_response at src/mock_vws/_flask_server/vws.py:140 and :157.
Moving the VWS and VWQ endpoint bodies into shared modules with that same signature would leave each backend as routing plus adaptation, remove the second copy of every handler, and let the configurable failure injections above work in Docker without further work.
This is large enough to want doing endpoint by endpoint rather than in one change.
What happens
The VWS endpoints are implemented twice:
src/mock_vws/_requests_mock_server/mock_web_services_api.py— 1068 linessrc/mock_vws/_flask_server/vws.py— 1016 linesThe same roughly fifteen endpoints appear in both. The bodies are frequently identical.
database_summaryis representative: the response dict, the header dict and theemail.utils.formatdatecall match line for line betweenmock_web_services_api.py:628andvws.py:707, differing only in how the request is read and how the response is built.The Query API is split the same way between
_requests_mock_server/mock_web_query_api.pyand_flask_server/vwq.py.Why it matters
The duplication is already causing the two backends to drift. These are supported in-process but not in Flask or Docker, and each is recorded in
differences-to-vws.rstas a limitation rather than implemented:cloud_query_failure_responsemodel_target_generation_failuremodel_target_generation_warningvumark_generation_failuresleep_fnand the response-delay timeout behaviourEvery new feature now costs two implementations or one implementation and one documented gap. Bugs follow the same pattern: #3368 exists only because the Flask backend does its routing and validation differently from the in-process one.
Suggested resolution
Extend the extraction which is already in place rather than inventing a new structure.
src/mock_vws/_model_target_web_api.pyandsrc/mock_vws/_reco_counts_web_api.pyare already backend-agnostic: they take aRequestDataand return a(status, headers, body)tuple, and both backends call them. The adapters exist too —_flask_request_dataand_to_flask_responseatsrc/mock_vws/_flask_server/vws.py:140and:157.Moving the VWS and VWQ endpoint bodies into shared modules with that same signature would leave each backend as routing plus adaptation, remove the second copy of every handler, and let the configurable failure injections above work in Docker without further work.
This is large enough to want doing endpoint by endpoint rather than in one change.