DM-11745: Investigate wrapping external function calls in ap_verify #10
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.
This PR adds a new decorator,
_MetricsRecovery
, topipeline_driver
for handling the shared metrics/job/metadata logic. Despite the discussion on DM-10779, I've opted not to replace the existing adapters with an assignment-like syntax. The reasons are twofold:ap_verify
's strategy for handling measurements norap_pipe
's API are finalized yet, and having explicit adapter functions will make it easier to absorb any changesap_verify
makes assumptions about how it interacts withap_pipe
(for example, any metadata must be in thegetFullMetadata()
format, andap_pipe
is expected to internalize details like its system of sub-repositories), and being able to document those assumptions explicitly will make the code easier to maintainWe can always replace the explicit wrappers with statements like
_ingestRaws = _MetricsRecovery(apPipe.doIngest)
later, once theap_*
packages have stabilized.