-
Notifications
You must be signed in to change notification settings - Fork 361
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: [M3-8332] - Use new "lish" API instead of "lish_token" #10656
Conversation
Coverage Report: ✅ |
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.
Use new lish
API ✅
Core regions load lish/glish the same as prod ✅
New endpoint returns WebSocket protocols for distributed regions ✅
WebSocket protocols are empty for core regions ✅
Is it expected that the lish console is blank for distributed regions? Granted it doesn't work for me in prod either (just displays a loading spinner)
Distributed region | Core region |
---|---|
* Remove ticket numbers. * Add `LinodeLishData` interface to pass around the result of the `lish` API. * Address eslint formatting issue.
It is expected that "distributed" will just spin because the backend configuration is not yet 100% complete. |
@plisiecki1 It seems like lish requests are being spammed for the distributed regions on this branch Screen.Recording.2024-07-10.at.12.13.29.PM.mov |
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.
Observed the lish
network request as expected in dev tools for weblish and glish, with empty protocols
for core regions, and session protocol for a distributed region.
Aside from Hana's last observation, feedback addressed + Hana's changes looked good to me.
@mjac0bs @bnussman-akamai @hana-linode - I have attempted to address the "spamming" of requests by improving the error/retry logic so that we can retry only several times within any short period of time. Is this too much to take in this change? We could go with the previously reviewed version and then take on the other improvements later on if that seems like a better approach. |
@plisiecki1 These are a lot of new changes, let's go back to the previous version and merge that, then open a follow up PR for improvements |
7b08325
to
a12b4d3
Compare
I just force pushed to revert the additional improvements, which we can work on in a separate follow-up PR. The code is now exactly the same commit which was previously reviewed. |
Description 📝
This change upgrades the backend weblish/glish session creation requests from the older
lish_token
API to a newerlish
API. This newer API includes support for both core and distributed regions.Changes 🔄
List any change relevant to the reviewer.
lish
API which returns the full URLs rather than leaving it up to cloud manager to compute. For core regions, this should result in the same URL as cloud manager would have computed.lish
API also returns values to use as WebSocket "protocols"; this will currently be an empty list for core regions, but include session information for distributed regions.Target release date 🗓️
ASAP
Preview 📷
There are no user-visible changes.
How to test 🧪
Create weblish and glish sessions against a host. It should work exactly as before for core regions. In the browser Developer Tools, you should see accesses to the
lish
endpoint and not thelish_token
endpoint.Prerequisites
No special setup is required.
Reproduction steps
N/A
Verification steps
See "How to test" above.
As an Author I have considered 🤔
Check all that apply
Commit message and pull request title format standards
<commit type>: [JIRA-ticket-number] - <description>
Commit Types:
feat
: New feature for the user (not a part of the code, or ci, ...).fix
: Bugfix for the user (not a fix to build something, ...).change
: Modifying an existing visual UI instance. Such as a component or a feature.refactor
: Restructuring existing code without changing its external behavior or visual UI. Typically to improve readability, maintainability, and performance.test
: New tests or changes to existing tests. Does not change the production code.upcoming
: A new feature that is in progress, not visible to users yet, and usually behind a feature flag.Example:
feat: [M3-1234] - Allow user to view their login history