-
Notifications
You must be signed in to change notification settings - Fork 307
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
Prevent register_launch_plan from re-registering already registered workflow #3049
Conversation
…w if it already exists Signed-off-by: Yee Hing Tong <[email protected]>
Code Review Agent Run Status
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3049 +/- ##
==========================================
- Coverage 83.47% 77.75% -5.72%
==========================================
Files 319 226 -93
Lines 26427 22959 -3468
Branches 2744 2746 +2
==========================================
- Hits 22060 17852 -4208
- Misses 3591 4346 +755
+ Partials 776 761 -15 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Yee Hing Tong <[email protected]>
Code Review Agent Run #345323Actionable Suggestions - 1
Additional Suggestions - 1
Review Details
|
Changelist by BitoThis pull request implements the following key changes.
|
Signed-off-by: Yee Hing Tong <[email protected]>
flytekit/remote/remote.py
Outdated
launch_plan_model, serialization_settings, version, create_default_launchplan=False | ||
) | ||
if ident is None: | ||
raise ValueError("Failed to register launch plan") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we raise this error in self.raw_register
? Also, are we able to add the error message here? Something like Failed to register launch plan with err: {err}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i say we keep this here until we can make the raw_register signature not an optional.
Signed-off-by: Yee Hing Tong <[email protected]>
…orkflow (#3049) Signed-off-by: Yee Hing Tong <[email protected]>
…orkflow (#3049) (#3054) Signed-off-by: Yee Hing Tong <[email protected]>
Code Review Agent Run #8550a9Actionable Suggestions - 2
Review Details
|
except FlyteEntityNotExistException: | ||
return False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding error handling for other potential exceptions besides FlyteEntityNotExistException
when calling get_workflow
. Network errors or other API issues could occur.
Code suggestion
Check the AI-generated fix before applying
except FlyteEntityNotExistException: | |
return False | |
except FlyteEntityNotExistException: | |
return False | |
except Exception as e: | |
logger.error(f"Error checking workflow existence: {e}") | |
return False |
Code Review Run #8550a9
Is this a valid issue, or was it incorrectly flagged by the Agent?
- it was incorrectly flagged
launch_plan_model, serialization_settings, version, create_default_launchplan=False | ||
) | ||
if ident is None: | ||
raise ValueError("Failed to register launch plan, identifier returned was empty...") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider using a more specific exception type like FlyteRegistrationException
instead of ValueError
when handling registration failures. This would make error handling more targeted.
Code suggestion
Check the AI-generated fix before applying
raise ValueError("Failed to register launch plan, identifier returned was empty...") | |
raise FlyteRegistrationException("Failed to register launch plan, identifier returned was empty...") |
Code Review Run #8550a9
Is this a valid issue, or was it incorrectly flagged by the Agent?
- it was incorrectly flagged
…orkflow (flyteorg#3049) Signed-off-by: Yee Hing Tong <[email protected]>
Tracking issue
Linking this to flyteorg/flyte#6062 which is related.
Why are the changes needed?
Please see comment in the linked issue, copied here:
Assume in the past
my_wf
has already been registered with versionksD2LBYDu5PrNtNnnpd95Q
Now if you try to do:
The issue is that
register_launch_plan
will currently try to register the underlying workflow again. This would be fine, except that the serialization settings that are used may be completely different. Even if it's exactly the same, this is a waste of time because the best case scenario is that Admin returns already exists for the workflow and every underlying task (and subwf, etc.).We should check first to see if the workflow already exists with that version, and only register the launch plan if the workflow already exists.
Skipping re-registration of the workflow does mean that users who were relying on this re-registration (and were somehow reconstructing serialization settings to be identical) to detect changes in workflow/task structure will no longer see errors, but that seems too far-fetched.
What changes were proposed in this pull request?
create_default_launchplan
) in_serialize_and_register
which for some reason wasn't used. Just a nit, default was always justTrue
.How was this patch tested?
Tested with local sandbox.
Setup process
Screenshots
Check all the applicable boxes
Related PRs
Docs link
Summary by Bito
This PR streamlines the launch plan registration process by implementing checks to prevent redundant workflow registrations. The changes enhance FlyteRemote by adding workflow existence verification and optimizing the registration flow. The implementation includes proper handling of create_default_launchplan parameter, improved error handling with specific exceptions, and better error messaging.Unit tests added: True
Estimated effort to review (1-5, lower is better): 1