Fix: hardcode handler_name = "lambda_function.lambda_handler" to match the zip entry name.

[mollyheamazon]

Issue #, if available:
Ticket: https://tiny.amazon.com/12ooeo0ys/tcorpamazP405over

Description of changes:

• One-line fix in evaluator.py line 385
• Updated test_create_with_byoc to assert the correct Handler value is passed to create_function

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[mufaddal-rohawala]

🤖 AI Code Review

This PR fixes a bug where the Lambda handler name was dynamically derived from the source file name, but the zip entry always uses 'lambda_function.py' as the module name. The fix is straightforward and the test update correctly validates the new behavior. However, there are two notable concerns: a direct boto3 call (pre-existing) and a missing explanation of why the handler name must be hardcoded.

[mufaddal-rohawala]

The fix itself makes sense if the zip archive always packages the source file as lambda_function.py regardless of the original filename. However, this introduces a subtle coupling — the hardcoded string "lambda_function.lambda_handler" must match whatever entry name is used when building the zip. Consider extracting this as a module-level constant (e.g., LAMBDA_HANDLER_NAME = "lambda_function.lambda_handler") and adding a comment explaining why it's hardcoded (i.e., the zip archive always renames the source to lambda_function.py). This will prevent future contributors from "fixing" it back to the dynamic version.

Also, as a pre-existing issue: this method calls boto3.client("lambda") directly (line 383). Per V3 architecture tenets, all AWS API interactions should go through sagemaker-core rather than calling boto3 directly. This is out of scope for this PR, but worth tracking.

[mollyheamazon]

mlops integ test failures is flaky test