Initial draft of a non-breaking option to support passing an extra "request context" parameter to handler override functions (transform_fn, input_fn, predict_fn, output_fn), ONLY when the signature of the provided function includes the extra parameter.
This should allow script mode users to access additional request context (such as the SageMaker CustomAttributes header) without breaking implementations using the existing function APIs.
Outstanding TODOs (hoping for input from reviewers!) include:
[ ] Agree the scope of the additional "context" object - the raw context object as per Transformer.transform() seems maybe too broad & not very user-friendly? I'm not even sure what API it offers
[ ] Validate the approach
[ ] Understand & complete relevant doc updates & downstream library updates (e.g. add the parameter in default handler fns here and in other libraries like the PyTorch and HuggingFace toolkits too? Update SageMaker Python SDK docs when new DLCs are available with this change built in?)
Testing done:
Added some unit tests to show initial non-breaking-ness, but would be nice to get an integration test too maybe?
Merge Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.
Issue #, if available: #110
Description of changes:
Initial draft of a non-breaking option to support passing an extra "request context" parameter to handler override functions (
transform_fn
,input_fn
,predict_fn
,output_fn
), ONLY when the signature of the provided function includes the extra parameter.This should allow script mode users to access additional request context (such as the SageMaker CustomAttributes header) without breaking implementations using the existing function APIs.
Outstanding TODOs (hoping for input from reviewers!) include:
context
object as perTransformer.transform()
seems maybe too broad & not very user-friendly? I'm not even sure what API it offersTesting done:
Added some unit tests to show initial non-breaking-ness, but would be nice to get an integration test too maybe?
Merge Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.General
Tests
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.