-
Notifications
You must be signed in to change notification settings - Fork 31
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
api/stream: Improve reliability of /setactive
API
#992
Conversation
We don't want to leave suspended streams indeterminately active in the database.
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/livepeer/livepeer-com/B4EtVyCzGz7oPdYJaQkmB6Zf8AjB |
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.
lgtm!
What does this pull request do? Explain your changes. (required)
This is to do a couple improvements in the
/setactive
API, specifically made for improvingreliability of it. This is especially important for our stream nuking APIs, since for those we need
a reliable source of "where is the stream?". In the worst case we can start fetching this info
from the Stream Health API, but I believe a very simple change to the
/setactive
API shouldalready make this a lot more reliable, especially against malicious actors like our soccer
streamers who have learned how to explore the bugs in that API.
Apart from that very simple change, inplemented here 8045d8d, also made a bunch of
improvements to the API performance, since I noticed from our metrics that it's already
running dangerously close to the
mist-api-connector
timeout a lot of the times: [grafana]Also did a small fix in the
/user/suspended
API here, just to avoid re-emailing the same userthat has already been suspended.
Specific updates (required)
/setactive: false
request for a suspended stream (only when active=true)/setactive
calls from sessions that are not the last one-
yarn test
also deployed to staging and checked things still work
Does this pull request close any open issues?
It is related to but does not close https://github.com/livepeer/livepeer-infra/issues/830
I'm hoping that this change will make a full backend calling the
kube-api
unnecessary.Our stream termination logic from the API should work perfectly.
Checklist: