-
Notifications
You must be signed in to change notification settings - Fork 6
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
Alter readiness check to use the is_ready API endpoint #278
Conversation
blindly trying the application frontend.
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.
looks good to me.
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.
looks good in general. couple notes:
- fetchOptions should get passed as the second arg of the axios.get, right now it's not being used.
- Also see that there's already a
getAppReady
method in the API. You should just replace that one with the new one, and make sure it's still working wherever the existing method was being used. Also make sure to update thegetAppReady
declaration in the IWorkspacesAPI interface, or you'll get errors. Also, just return a boolean, not an object with anis_ready
property. Part of the role of the API is to parse the raw API response into something more easily useable.
…o use new endpoint
updated to conform to suggestions |
Looks good, only gripe is the api call should be try caught by the user, not inside the call itself. Putting it inside the api call can mess up some of the error handling |
Hmm yeah true, but I'll also say that in both of the calling contexts where it is invoked, the code treats an error the same as false and simply blindly retries the call after a pause. |
Yeah but it’s about code consistency. And also like I said, the error handling in the code for any APIRequest method breaks if you catch errors inside the request, so it literally breaks the code in edge cases to do that
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Jeff Waller ***@***.***>
Sent: Thursday, October 12, 2023 11:05:45 AM
To: helxplatform/helx-ui ***@***.***>
Cc: Roupe, Griffin ***@***.***>; Review requested ***@***.***>
Subject: Re: [helxplatform/helx-ui] Alter readiness check to use the is_ready API endpoint (PR #278)
Hmm yeah true, but I'll also say that in both of the calling contexts where it is invoked, the code treats an error the same as false and simply blindly retries the call after a pause.
—
Reply to this email directly, view it on GitHub<#278 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHRKQOLHZBASASEJTY7OCO3X7ABMTAVCNFSM6AAAAAA52Y2WLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJZG44TGMRRG4>.
You are receiving this because your review was requested.Message ID: ***@***.***>
|
modded the try-catches too. |
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.
very cool !
Add support for checking the readiness of an App in a different way. Previously, the UI (splash screen) would try to
connect the main interface of the App. With this change, it instead checks against a new API endpoint.
/v1/instances/{sid}/is_ready/
. The result will be false until the pod underlying the App passes its readiness probe.