-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
fix(types)!: improve types in index.ts #720
Conversation
Codecov Report
@@ Coverage Diff @@
## master #720 +/- ##
==========================================
+ Coverage 99.23% 99.28% +0.04%
==========================================
Files 15 15
Lines 15735 15724 -11
Branches 953 952 -1
==========================================
- Hits 15615 15611 -4
+ Misses 117 110 -7
Partials 3 3
Continue to review full report at Codecov.
|
@@ -59,16 +59,21 @@ export type GetClustersCallback = ( | |||
clusters?: Cluster[], | |||
apiResponse?: google.bigtable.admin.v2.IListClustersResponse | |||
) => void; | |||
export interface SetClusterMetadataOptions { | |||
nodes: number; |
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.
Only nodes
are updatable in cluster after it's creation
src/cluster.ts
Outdated
if (metadata.location) { | ||
reqOpts.location = Cluster.getLocation_( | ||
this.bigtable.projectId, | ||
metadata.location | ||
); | ||
} | ||
|
||
if (metadata.nodes) { | ||
reqOpts.serveNodes = metadata.nodes; | ||
} | ||
|
||
if (metadata.storage) { | ||
reqOpts.defaultStorageType = Cluster.getStorageType_(metadata.storage); | ||
} | ||
|
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.
storage
and location
can not be updated on an existing cluster
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 haven't tested this or anything, but the docs say that the UpdateCluster rpc accepts a full "Cluster" object: https://cloud.google.com/bigtable/docs/reference/admin/rpc/google.bigtable.admin.v2#google.bigtable.admin.v2.BigtableInstanceAdmin.UpdateCluster-table
Will it return an error if certain fields are attempted to be updated?
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.
It won't return an error,
This change is done to eliminate a possibility of a confusion from the user side if attempted to change a filed that is not supported.
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 see, thanks. I'm not sure we should use the whitelist approach of only allowing "serveNodes", when the API could evolve someday to accept something else, and we'd be blocking it. Does the upstream team know their API docs state multiple unsupported properties can be sent during the UpdateCluster call, and maybe they would want to make it return an error from their end, or some other solution?
We could also throw from our library if we receive unsupported input, but in general, we're best to simply match what the official docs state is supported. As soon as we go off that path, things get shaky.
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.
Does the upstream team know their API docs state multiple unsupported properties can be sent during the UpdateCluster call
While UpdateCluster rpc does accept a full "Cluster" object, it seems that upstream API docs do specify that among Cluster
properties
name
is an OutputOnly fieldstate
is an OutputOnly field as welllocation
is a CreateOnly fielddefault_storage_type
is a CreateOnly field as well- leaving only
serveNodes
field that can be updated
when the API could evolve someday to accept something else, and we'd be blocking it
If/when upstream API evolves to accept something else, that logic could be added as a new feature PR?
WDYT?
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.
If/when upstream API evolves to accept something else, that logic could be added as a new feature PR?
There's usually a big lag before we notice.
If the upstream API silently drops properties, I would think our best bet is to do the same. In terms of code, let's pass them all through. In terms of types, maybe that's where you could just list "serveNodes"? At least then, if the user knows better and is trying to set a property we haven't added to the types yet, they could have their TypeScript compiler ignore that (I think?).
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.
Added the logic back, left the types with nodes
only.
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.
@stephenplusplus WDYT?
nextQuery?: {} | null, | ||
response?: google.bigtable.admin.v2.IListInstancesResponse | null | ||
result?: Instance[], | ||
failedLocations?: string[], |
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.
BREAKING CHANGE
exposing failedLocations
in the callback/response
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.
Let's make sure we add docs for this new response argument.
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.
Also, an example in the code block showing "if (failedLocations.length > 0) { // These locations contain instances which could not be retrieved. }"
export interface ClusterInfo { | ||
id?: string; | ||
location?: string; | ||
serveNodes?: number; | ||
nodes?: number; | ||
storage?: string; | ||
defaultStorageType?: number; |
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.
BREAKING CHANGE
Removing serveNodes
and defaultStorageType
as these are expected by GAPIC client, user facing parameters are nodes
and storage
respectively.
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 don't think our parser is smart enough for BREAKING CHANGES, to pull in the bullets. So I'd just do:
BREAKING CHANGE: cluster.setMetadata(): only node count is updatable on an existing cluster; getInstancesCallback/Response: dropped nextQuery property as it is deprecated for this method; etc
@AVaksman we prolly want to land this before shipping v3, right? Can I trouble you to run through the open PRs and try to get these ready to go? |
BREAKING CHANGE:
|
src/cluster.ts
Outdated
}; | ||
|
||
if (metadata.location) { | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
if ((metadata as any).location) { |
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.
If the API actually drops these parameters, I think we can skip all of the logic where we worry about formatting them.
src/cluster.ts
Outdated
? gaxOptionsOrCallback | ||
: ({} as CallOptions); | ||
|
||
const reqOpts: ICluster = { | ||
name: this.name, | ||
serveNodes: metadata.nodes, |
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.
This is where I think we should pass all user-provided input straight through, as opposed to the whitelist approach where we only recognize certain parameters.
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.
(mapping metadata.nodes
to serveNodes
is still good)
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.
If applicable, user will need to pass
the location
as a full path in the form of
projects/<project>/locations/<zone_id>
and a defaultStorageType
(not storage
) param with a value in upper case characters.
Done
@stephenplusplus before merging, does PR description look OK?
|
It looks good to me! |
BREAKING CHANGE: cluster.setMetadata(): only node count is updatable on an existing cluster; getInstancesCallback/Response: dropped nextQuery property as it is deprecated for this method, exposed failedLocations property; instance.createCluster(): removed unsupported params serveNodes and defaultStorageType
Improve type annotations, some clean up and minor refactoring.