graphqlbackend: add permissionsSyncJobs query#44387
Conversation
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
Bundle size report 📦
Look at the Statoscope report for a full comparison between the commits 08153cc and d2e4f01 or learn more. Open explanation
|
6b0db24 to
eeb2359
Compare
ba45511 to
3cde488
Compare
eeb2359 to
013067d
Compare
3cde488 to
fa813d6
Compare
013067d to
fd4c405
Compare
There was a problem hiding this comment.
We already have a standard way to do pagination. Based on PageInfo type defined in graphql (IIRC). Which in turn is based on cursor pagination, not offset and limit.
I think we can reuse it instead of introducing custom code. The convention is then to ask for
first: Int
after: String
Where first is basically the limit as you use it. And after is the cursor that points to the item after which want to get the next page worth of items. You can see it in action on org members here.
There was a problem hiding this comment.
Ah, I copied this from another endpoint here. That said, I currently don't intend for this endpoint to be paginated - it should only ever return the X most recent runs, older runs will expire and should not be paginated for
There was a problem hiding this comment.
For now I'm opting to not implement pagination here, since the endpoint and data are not designed to return enough data to warrant pagination at the moment. I've updated various docstrings, and also made the data retention a more aggressive 5m by default (https://github.com/sourcegraph/sourcegraph/pull/44258)
There was a problem hiding this comment.
I did rename count to first, however, so the parameters can one day be extended to paginate if needed!
enterprise/cmd/frontend/internal/authz/resolvers/permissions_sync_jobs.go
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I think you can consider splitting all of these resolvers into their own file. They seem to be completely separate from responsibility point of view.
There was a problem hiding this comment.
I think I will keep these in the same file for now - they are both very thin adapters for the GraphQL interfaces, and it seems the general practice is to keep them together (e.g. the bitbucket endpoint resolver)
enterprise/cmd/frontend/internal/authz/resolvers/permissions_sync_jobs.go
Outdated
Show resolved
Hide resolved
fa813d6 to
f78b88d
Compare
1d82a35 to
b4cba34
Compare
5169b47 to
17edfe2
Compare
e2287c5 to
f6e62b8
Compare
57cdeed to
244d49a
Compare
1465a70 to
480e5ec
Compare
5eaae52 to
edeecce
Compare
567ede0 to
f030783
Compare
3b69175 to
0e21a6c
Compare
eseliger
left a comment
There was a problem hiding this comment.
lgtm, pending implementing the remaining comments (not sure if review was re-requested intentionally yet?)
There was a problem hiding this comment.
yeah I think that's ok, if we want to avoid confusion we might want to rename it to something else if we got anything better, but not strictly required.
eseliger
left a comment
There was a problem hiding this comment.
LGTM, pending one last thing for Node
There was a problem hiding this comment.
This resolver should have a method called NodeResolvers
Should be called like that: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/cmd/frontend/graphqlbackend/graphqlbackend.go?L366 for the authz resolver in the same method
For that, add to the interface type this signature https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/cmd/frontend/graphqlbackend/batches.go?L302
Finally, the NodeResolvers method should return a mapping from Kind to a resolver func.
There was a problem hiding this comment.
Thanks, added and tested! https://github.com/sourcegraph/sourcegraph/pull/44387/commits/1687dfe48c520525e2aee023fcd20f9057d87fa5
enterprise/cmd/frontend/internal/authz/resolvers/permissions_sync_jobs.go
Outdated
Show resolved
Hide resolved
3541b9b to
a37cf74
Compare
Co-authored-by: Erik Seliger <erikseliger@me.com>
Co-authored-by: Erik Seliger <erikseliger@me.com>
1687dfe to
ba0c0db
Compare
Changes to make query align with pagination/Node paradigms made and reviewed by Erik
| type recordsReader struct { | ||
| // readOnlyCache is a replaceable abstraction over rcache.Cache. | ||
| readOnlyCache interface { | ||
| ListKeys(ctx context.Context) ([]string, error) |
There was a problem hiding this comment.
@bobheadxi sorry to revive an old PR. But I've been reviewing our use of redis and noticed this use of ListKeys. FYI this operation has the complexity of listing all keys on the redis instance, not just those associated with the named cache. It will only return the relevant keys, but redis doesn't have a way to do this otherwise.
How many keys do you expect us to get? From looking around, it seems like this would be better suited using rcache.FIFOList. WDYT?
Instead of this
There was a problem hiding this comment.
The FIFOList wasn't available at the time, but I did spot it in other PRs - I can make the switch here :) Will open a PR tomorrow!


Adds a new
permissionsSyncJobsthat returns the most recent outcomes of permissions sync jobs, with per-provider details included. This will be used to validate permissions syncing is starting correctly and the desired providers are being involved and in a healthy state.We don't implement pagination since the endpoint is intended as a stream of recent events and retention is low (see https://github.com/sourcegraph/sourcegraph/pull/44258), but the endpoint schema is set up so that it can be extended to support pagination in the future.
Closes https://github.com/sourcegraph/customer/issues/1534
Stacked on https://github.com/sourcegraph/sourcegraph/pull/44258
Test plan
Add a GitHub code host with
"authorization": {}, and add a private repo to the listWait a few minutes
Remove the token:
Get by ID: