Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
New admin method for fetching group offsets for multiple topics #992
New admin method for fetching group offsets for multiple topics #992
Changes from 11 commits
a72d09f
a2216eb
e940948
231ebee
5f42dbe
7a575d0
cef4830
fa0ea86
d6b4cf3
8943aa5
b7b06e0
5f5ac39
bb9567b
23e17e2
ca704d1
5786968
2f190a7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm not sure how to write the JSDoc for this, now that the interplay between
topic
andtopics
is more complicated.Both
topic
andtopics
are optional. If neither is set, the default is fortopics
to get the value[]
. Do you know if there's any way to express that in JSDoc, @ankon? Not a big deal, but I just don't know.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.
Interesting, from the top of my head: I think this might be too much to express with JSDoc. There could be a way to do it in the TypeScript definition, and then you could do magic with
@type
here.But it also might not be needed: If these are optional, then from the callers point that's all they need to know. The specific defaulting could just be considered an implementation detail.
I guess I would just go with
I guess the reason you need both
topic
andtopics
is that the function is part of the API, i.e. you're providing backwards-compatibility. Could this not be achieved by adding a new function (sayfetchTopicOffsets
), and then eventually deprecate the old one?Another approach for consideration, closer to what the .d.ts would do given your later comment :)
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.
I added comments as @ankon suggested, inline in the parameter list as well.
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.
Github won't let me create a suggestion that goes outside of the lines of the diff, but there's an issue here where the return type of this function is different depending on the input, so we need to be a little more clever here. There's probably some fancy-pants thing you can do with conditional types, but we can also just use plain old method overloading:
This has a few benefits. The first is that the type system will prevent
admin.fetchOffsets({ topic: 'foo', topics: ['bar'] })
, because thetopic
andtopics
properties are mutually exclusive. The second is that it allows us to define the relationship between the input type and the return type. The return type is a bit of an abomination. If we didn't returnmetadata
it could be simplified to justPromise<TopicOffsets[]>
andPromise<PartitionOffset[]>
, but alas, here we are.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.
Done. I've opted to keep the options parameter inline though, but moved the
Array<PartitionOffset & { metadata: string | null }>
to a new type. LMK if you prefer the options to be extracted to a type as well.