Skip to content

fix(core): don't poll or stream CloudWatch logs for local processing jobs - #6428

Open
AkshayShah03 wants to merge 1 commit into
aws:masterfrom
AkshayShah03:fix/local-processing-skip-wait
Open

AkshayShah03 wants to merge 1 commit into
aws:masterfrom
AkshayShah03:fix/local-processing-skip-wait

Conversation

@AkshayShah03

Copy link
Copy Markdown

Issue #, if available: Relates to #5549

Description of changes:

In local mode, the processing container runs to completion inside _start_new: LocalSagemakerClient.create_processing_job calls _LocalProcessingJob.start, which streams the container output until it exits and then marks the job Completed. The job only exists locally.

Since #6369, Processor.run and ScriptProcessor.run with wait=True go through the module-level logs_for_processing_job (the default logs=True) or _wait_for_processing_job. The DescribeProcessingJob call from #5549 now goes to the local client. logs_for_processing_job, however, still tails CloudWatch through the session's boto session, so a local job fails after it has succeeded when there are no AWS credentials or no CloudWatch permissions.

v2 avoided this through LocalSession.logs_for_processing_job, a no-op that v3's LocalSession still defines, but the module-level helper bypasses it.

This change skips the wait for a LocalSession, since the job is already complete. It uses isinstance(..., LocalSession) rather than getattr(..., "local_mode"), so the existing tests that use plain Mock() sessions keep exercising the wait paths.

Testing:

  • New tests for Processor and ScriptProcessor in local mode, each with logs=True and logs=False. All 4 fail before this change.
  • tests/unit/test_processing.py and the model monitor tests: 224 passed.

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

…jobs

In local mode the processing container runs to completion inside
_start_new (the local client's create_processing_job), and the job only
exists locally. Since aws#6369, Processor.run/ScriptProcessor.run with
wait=True still went through logs_for_processing_job (the default
logs=True), which tails CloudWatch via the boto session, or
_wait_for_processing_job. Without AWS credentials or CloudWatch access that
fails after the job has already succeeded. v2 avoided this through a no-op
LocalSession.logs_for_processing_job, which the module-level helper now
bypasses.

Skip the wait for LocalSession, since the job is already complete.

Relates to aws#5549

This branch is waiting to be deployed

1 waiting deployment
manual-approval — ace84fd1 Waiting Oct 10, 2026 by AkshayShah03 via wait-for-approval #610
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant