Skip to content

Conversation

@aws-asolidu
Copy link
Contributor

@aws-asolidu aws-asolidu commented Jul 16, 2025

Problem

  • When reconnecting to multiple SageMaker Spaces (either via deeplink or from within the VS Code extension), a race condition occurs when writing to shared temporary files. This can cause the local SageMaker server to crash due to concurrent access.
  • Need clearer error messaging when reconnection to a deeplinked space is attempted without an active Studio login.

Solution

  • For connections initiated from the VS Code extension, we generate unique temporary files to read the response json.
  • For deeplink-based reconnections, we introduce a queue to process session requests sequentially.
  • Add remote_access_token_refresh flag to the refresh URL to enable the Studio server to return more specific error messages.

  • Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
  • Your code changes must meet the guidelines in CONTRIBUTING.md.
  • License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

@aws-asolidu aws-asolidu requested a review from a team as a code owner July 16, 2025 17:24
@github-actions
Copy link

  • This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
    • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
    • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

@NewtonDer
Copy link
Contributor

Need to generate a changelog entry with npm run newChange -w packages/toolkit

}

writeQueue.push(writeOperation)
processWriteQueue().catch(reject)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

processWriteQueue().catch this catch cannot catch anything because inside processWriteQueue it does not throw.

Copy link
Contributor Author

@aws-asolidu aws-asolidu Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I’ll remove this. Since processWriteQueue uses a try/finally block there's nothing to catch, and writeOperation already handles errors and calls reject.

@chungjac chungjac merged commit 2eb0891 into aws:master Jul 16, 2025
22 checks passed
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.

6 participants