Closed Mark-Simulacrum closed 2 years ago
Some thoughts about the possible implications (please validate my assumptions because I'm not 100% sure):
moving the agenda generation online wouldn't allow me to test locally little tweaks that I might want to submit as future patches (ex. #1593). Being able to run the tool both locally and online wouldn't remove this capability.
Today, anyone generating T-lang and T-compiler agenda use their own GH token to run queries so there's a vague user access control. With a completely online version I assume everyone would use the same token (set server-side)? We would lose this granularity.
How would that solve the rate-limiting issue? If I'm hitting the GH API too often then someone else would be impacted, too.
(related to the above point) Caching, in this context, would also be a tiny step backwards in my workflow because it wouldn't allow generating an agenda immediately after operating on other things online (say, updating issue/PR labels). A flag to choose whether to use the cache or not wouldn't remove this capability.
We could still support running it locally, either via existing method directly or by running the site. I don't expect the story there to get significantly worse.
For the configuration use case, I expect we could expose that if desired (as a query param). It would mean more complicated caching, but not too much.
I'm not sure I understand the user access control angle - this is all querying public data, right? I'm not seeing why per user tokens help us much. I could easily be missing something though!
I would expect that if you're working on the agenda actively (e.g., modifying labels) you probably still want to run a local copy. I think it's possible we could have the caching later directly on the GitHub queries (using if-not-modified or whatever the right hradee is), which would ease concerns around rate limiting, but I suspect the workflow you have would continue to be best served with a local run. (I will note that we have the long term ability to migrate triagebot to be a GitHub app, which will increase our rate limit roughly 3x I think, and depending on whether we want to, for this particular interface we could do the full oauth flow to make each user have their own rate limit pool. This is a lot of work though.)
In general I think the lang workflow here is much simpler than yours, so my hope is we can meet that need and then move forward from there.
agree on your comments :+1: I'll just clarify this point I didn't explain too well:
I'm not sure I understand the user access control angle - this is all querying public data, right? I'm not seeing why per user tokens help us much
by "user access control" I just meant that using a single shared server-side token would also share responsabilities. A user being rate limited (for any reason, not necessarily a bad actor) would block everyone using that token.
This is done for lang agendas; those are currently rate limited to 1 request every 30 seconds, which is enough to prevent problems on the github side. I don't think this causes any difficulty for regular usage of the endpoint, though we don't have metrics in place to validate that assumption (probably good to add them).
For now, I think this is basically done; we can extend it with compiler agendas and other things at a later point if desired pretty easily.
Cool! w.r.t. the rate limiting issue incurring in the T-compiler agenda I have a log of all the REST traffic performed. I'd like to investigate if moving some of them to the github GraphQL endpoint would help reducing the number of calls.
Currently lang and compiler agendas are generated by running the tooling locally, but that can mean a recompile and is generally heavier weight than just visiting a webpage. It should be pretty easy to move the entry points into the triagebot library (rather than lang-agenda...) and then serve them from the existing HTTP server.
Since they run a number of pretty rate limited GH queries, it's probably a good idea to cache the produced markdown within triagebot for ~5-10 minutes or so. That shouldn't be too hard to do; likely hand rolling it is easiest.