Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Update the "Continue Single trial experiment" workflow #8526

Merged
merged 36 commits into from
Dec 12, 2023

Conversation

julian-determined-ai
Copy link
Contributor

@julian-determined-ai julian-determined-ai commented Dec 1, 2023

Description

Implements the "Continue Trial" workflow as described in WEB-1857

Test Plan

  1. Navigate to an experiment list page.
  2. Navigate to a completed experiment where the searcher is single.
  3. Click "Continue Trial" and ensure you see a dropdown with the options "Create New Experiment..." and "Reactivate Current Trial..."
  4. Click "Create New Experiment..." ensure the design and text match the Figma.
  5. Click "Reactivate Current Trial..." ensure the design and text match the Figma.
  6. Click "Create New Experiment..." ensure that the behavior matches the current "Continue Trial" flow (same modal as in step 1)
  7. Click "Reactivate Current Trial..." .
  8. Click "Show Full Config" and take note of the current "max_length"
  9. Click "Show Simple Config" and input a positive number, check the full config again and make sure that the number was added to the "max_length"
  10. Edit the "max_length" in the full config and click show simple config, ensure that the new additional value is equal to the (new max length - original config max length)
  11. Edit the "max_length" in the full config to be an invalid value, for example a string, or float, or delete the max value entirely and click show simple config, ensure that the additional value field is blank.
  12. In the simple config enter a valid value for "additional 'length' (this could be batches, epochs, or another unit)" and click "Reactivate Trial" ensure that the submissions is successful.
  13. Navigate to an incomplete single trial experiment.
  14. Click Continue Trial then "Reactivate Current Trial..." Ensure that the design matches the figma and you can only see the "full config" option and cannot switch to the simple config.
  15. Click "Reactivate Trial" ensure that the submissions is successful.
  16. Navigate to a completed experiment where the searcher is single. Ensure your screen size is large enough to see the "Continue Trial" button.
  17. Click the overflow menu (the three vertical dots) ensure that you do not see "Create New Experiment" or "Reactivate Experiment".
  18. Decrease your screen size until you cannot see the "Continue Trial Button" ensure that you can see "Create New Experiment" and "Reactivate Experiment"
  19. Ensure you can only see the Continue Trial option for canceled, errored, completed, and/or deleted failed experiments.

Commentary (optional)

Checklist

  • Changes have been manually QA'd
  • User-facing API changes need the "User-facing API Change" label.
  • Release notes should be added as a separate file under docs/release-notes/.
    See Release Note for details.
  • Licenses should be included for new code which was copied and/or modified from any external code.

Ticket

WEB-1857

Copy link

netlify bot commented Dec 1, 2023

Deploy Preview for determined-ui ready!

Name Link
🔨 Latest commit 91ead1b
🔍 Latest deploy log https://app.netlify.com/sites/determined-ui/deploys/6578cea810b0790008361d90
😎 Deploy Preview https://deploy-preview-8526--determined-ui.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link
Contributor

@gt2345 gt2345 left a comment

Choose a reason for hiding this comment

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

Do you think we can consolidate the Continue trial modal into the current Fork modal?

Some user experience comments:
When reactivating experiment, should we limit the parameters user can change in full config? For example, I can change workspace and project in full config, but the reactivated experiment should still be at the current project.
Should we allow continue/reactivate function when the experiment is running?

))}
{options?.slice(0, 3).map((option) =>
option?.content ? (
option.content
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems a bit hacky in my opinion, do you think there might be a way around it? Such as options?: (ButtonOption | DropdownOption)[]?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@gt2345 I could do that, I would then have to update several codepaths to handle either type which also felt a but hacky.

To me it seems a little weird to force us to only show a "Button" or "Dropdown" here. It seems possible that one day we might want to show an icon, or freeform text, or some other component here. I can do this but this seemed like a more future-proof approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@gt2345 I made several updates to this. We can now show any react node, and show multiple actions per react node, the latter was needed to show both of the actions in the button dropdown on the overflow list.

webui/react/src/components/ExperimentContinueModal.tsx Outdated Show resolved Hide resolved
@julian-determined-ai
Copy link
Contributor Author

When reactivating experiment, should we limit the parameters user can change in full config

@gt2345 I updated the UI to show an error if the Workspace or Project is changed

@julian-determined-ai
Copy link
Contributor Author

Do you think we can consolidate the Continue trial modal into the current Fork modal?

Some user experience comments: When reactivating experiment, should we limit the parameters user can change in full config? For example, I can change workspace and project in full config, but the reactivated experiment should still be at the current project. Should we allow continue/reactivate function when the experiment is running?

@gt2345 for the last point I have updated this for only terminal states.

@julian-determined-ai
Copy link
Contributor Author

julian-determined-ai commented Dec 5, 2023

@gt2345

Do you think we can consolidate the Continue trial modal into the current Fork modal

I actually started this work doing that at first. Ultimately, I ended up making a separate modal and just moved any shared functions to a util file. There is enough difference in the modals that I think trying to fit all of the differing functionality in one modal would result in a single overly complex component.

@gt2345
Copy link
Contributor

gt2345 commented Dec 5, 2023

When reactivating experiment, should we limit the parameters user can change in full config

@gt2345 I updated the UI to show an error if the Workspace or Project is changed

Thanks for being open to it, but I think it might be best if we loop into backend to decide the full list of properties that cannot be modified with this continue action.
Also the message shows up when I change the workspace/project, but does not disappear when I change things back...

Copy link
Contributor

@gt2345 gt2345 left a comment

Choose a reason for hiding this comment

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

Happy path works as expected, the thing I'm not sure is that could there be other config parameters that cannot be modified for continue action, and do we care that if the submitted config is inconsistent with the actual config?

</React.Suspense>
)}
{!isReactivate && !modalIsInAdvancedMode && (
<Body>Start a new experiment from the current trial&rsquo;s latest checkpoint.</Body>
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be a grayish text color if possible according to design file

Copy link
Contributor

Choose a reason for hiding this comment

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

Theoretically yes we should have some validation (around what is a valid config) but I think we're ok to leave feature parity with the current continue feature since that is broader scope

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @hkumar92 for clarification.
@julian-determined-ai Can we still address the style if possible?

webui/react/src/components/ExperimentContinueModal.tsx Outdated Show resolved Hide resolved
@julian-determined-ai
Copy link
Contributor Author

julian-determined-ai commented Dec 7, 2023

@gt2345

Also the message shows up when I change the workspace/project, but does not disappear when I change things back...

I cannot recreate this, can you give me steps to reproduce the issue>

CD429A40-5613-4B2A-AAD6-EF70E663E912.mov

@gt2345
Copy link
Contributor

gt2345 commented Dec 7, 2023

@gt2345

Also the message shows up when I change the workspace/project, but does not disappear when I change things back...

I cannot recreate this, can you give me steps to reproduce the issue>

CD429A40-5613-4B2A-AAD6-EF70E663E912.mov

Interesting, I don't see anything we are doing differently... Also I suppose it's okay to remove this functionality based on what Haran said?

Screen.Recording.2023-12-07.at.12.17.29.PM.mov

@gt2345
Copy link
Contributor

gt2345 commented Dec 12, 2023

Overall looks great, notices one unusual behavior. When the modal opens for the first time, the button should be disabled but not (which if fine), but when navigate to full config then navigate back, the additional batch field is auto filled. Is this by design?

Screen.Recording.2023-12-12.at.11.43.12.AM.mov

@julian-determined-ai
Copy link
Contributor Author

Overall looks great, notices one unusual behavior. When the modal opens for the first time, the button should be disabled but not (which if fine), but when navigate to full config then navigate back, the additional batch field is auto filled. Is this by design?

Screen.Recording.2023-12-12.at.11.43.12.AM.mov

@gt2345 this is actually by design and as intended. I agree that the behavior is a bit awkward. I think re-visiting this when/if we decide to change how we validate changes in the full config makes sense though.

Copy link
Contributor

@gt2345 gt2345 left a comment

Choose a reason for hiding this comment

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

LGTM

@julian-determined-ai julian-determined-ai merged commit 660de26 into main Dec 12, 2023
65 of 77 checks passed
@dannysauer dannysauer added this to the 0.26.7 milestone Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants