Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix: adjust workspace claims to be initiated by users#20179

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
SasSwart wants to merge2 commits intomain
base:main
Choose a base branch
Loading
fromjjs/internal-934

Conversation

SasSwart
Copy link
Contributor

@SasSwartSasSwart commentedOct 6, 2025
edited
Loading

The prebuilds user never initiates a workspace claim autonomously. A claim can only happen when a user attempts to create a workspace. When listing prebuild provisioner jobs, it would not make sense to see jobs related to users who are creating workspaces and have gotten a prebuilt workspace. When cleaning up an overwhelmed provisioner queue, we should not delete claims as they have humans waiting for them and are not part of the thundering herd.

Therefore, this PR ensures that provisioner jobs that claim workspaces are considered to be initiated by the user, not the prebuilds system.

@SasSwartSasSwart changed the titlefix: workspace claims are initiated by usersfix: adjust workspace claims to now initiated by usersOct 6, 2025
@SasSwartSasSwart changed the titlefix: adjust workspace claims to now initiated by usersfix: adjust workspace claims to be initiated by usersOct 6, 2025
@SasSwartSasSwart marked this pull request as ready for reviewOctober 6, 2025 12:15
Copy link
Contributor

@ssncferreirassncferreira left a comment

Choose a reason for hiding this comment

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

I like this change, it makes sense for the initiator to be the user who actually claims the prebuild rather than the system user 👍

I only have one concern: after this change, existing data in the database will have mixed information. Olderworkspace_build rows will have the prebuilds system user as the initiator, while new ones will have the user who claimed the workspace. This means the data becomes inconsistent in how the initiator is represented.

I don’t think this will be an issue in practice, but it’s definitely something we should document in case we add future database queries or analytics that rely on this field. Maybe a short code comment or note in the schema would help make that clear?

@johnstcn
Copy link
Member

existing data in the database will have mixed information. Older workspace_build rows will have the prebuilds system user as the initiator, while new ones will have the user who claimed the workspace. This means the data becomes inconsistent in how the initiator is represented.

I can see an argument for creating a migration to update the existing schema, as the initiator ID shows up in the following tables:

  • workspace_builds
  • provisioner_jobs
  • audit_logs (e.g. search forresource_type:workspace_build username:prebuilds).

I'd suggest keeping it out of scope of this PR.

The fact that this change hasn't requiredany updates to existing tests is mildly concerning though.

ssncferreira reacted with thumbs up emoji

@ssncferreira
Copy link
Contributor

The fact that this change hasn't requiredany updates to existing tests is mildly concerning though.

Agree 💯 I don't think we test the initiator ID 😕 so it might actually be a good idea to also add a test to cover this new change!

@SasSwart
Copy link
ContributorAuthor

We have a thorough test suite on prebuild claiming already.
I've added assertions to it to ensure that the initiator is set correctly in each case.

Copy link
Contributor

@ssncferreirassncferreira left a comment

Choose a reason for hiding this comment

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

LGTM 👍 Thank you for adding the tests.
Regarding the possible migration to update the existing schema, we can do that on a follow-up PR or create a separate issue.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@ssncferreirassncferreirassncferreira approved these changes

@johnstcnjohnstcnAwaiting requested review from johnstcn

Assignees

@SasSwartSasSwart

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@SasSwart@johnstcn@ssncferreira

[8]ページ先頭

©2009-2025 Movatter.jp