Skip to content

Conversation

JosephBorodach
Copy link
Member

Description

Add user-defined metadata CRUD operations

See ticket here

Todo

  • Do I need to manually test?

@JosephBorodach JosephBorodach requested a review from a team as a code owner March 4, 2025 14:18
@JosephBorodach JosephBorodach requested review from stuqdog, purplenicole730 and njooma and removed request for njooma March 4, 2025 14:18
* @param id The ID of the robot
* @returns The metadata associated with the robot
*/
async getRobotMetadata(id: string): Promise<GetRobotMetadataResponse> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mix/match prepending the type of object to Id: locationId and organizationId, but just id for robot and robotPart. Let's try to be consistent? Even if the proto has different names, we can make the user-facing API consistent.

I don't mind one way or the other, maybe a slight preference to just id everywhere since the object is already specified in the method name, but I'm never against hyper-specificity if you want to do robotId

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which actually brings up another question -- do we want to call it robot or machine?

Copy link
Member Author

@JosephBorodach JosephBorodach Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for calling this out - I agree we should be consistent, let's go with id!

My gut tells me robot because that's what we called it on the protos end of things, but what do you think?

If you prefer machine, that is fine by me!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to ask @JessamyT here for docs perspective: should we be using robot or machine? Most other functions are still using robot, so do we try for consistency, or do we start the migration to machine?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My uninformed inclination is to migrate towards machine since we do use that everywhere throughout the docs, even when talking about SDKs that use robot. Like we basically say robot = machine all over the place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good - thanks for chiming in!!

Copy link
Member

@edobranov edobranov Mar 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(drive by comment since I'm referencing this for RSDK-10138)

I'm wondering if we actually want to use "machine" here right now. Like we pointed out, all other methods in this sdk (and the Go one) are centered around "robot", so as a new user, I'd find myself kinda confused as to why they're mixed (I have to reference our glossary from time-to-time to remind myself of the relationship between machines/robots, parts, components, etc).

IMO from a purely UX perspective, it would be clearer to continue with "robot" for consistency. We could add a docs note reminding users that robot = machine and eventually rename the methods all at once, probably with an interim deprecation. I'm still new to the ethos/process behind this, so totally okay if that's beyond our usual scope of effort!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see that being useful. particularly when searching for functions, you could try to do a find for robot and see all the functions available on a robot. @JessamyT can we call this robot and then to a formal migration when we're ready to rename everything to machine?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@njooma @JessamyT - is it ok with you if we stick with robot in this pr and we cut a ticket to migrate everything over to machine at some point? I do not feel strongly one way or the other

@JosephBorodach JosephBorodach requested a review from njooma March 5, 2025 16:31
Copy link
Member

@stuqdog stuqdog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A small suggestion, otherwise looks good!

@JosephBorodach JosephBorodach requested a review from stuqdog March 6, 2025 15:22
Copy link
Member

@njooma njooma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two comments I left are applicable to all methods added

Comment on lines 1192 to 1193
): Promise<GetOrganizationMetadataResponse> {
return this.client.getOrganizationMetadata({ organizationId: id });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should return a dictionary here. Since the rpc returns a Struct, we should be able to convert that Struct into a native JS obj to make it easier for users to work it

Copy link
Member Author

@JosephBorodach JosephBorodach Mar 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do things look good as I have them now? I am having a really hard time getting the unit tests to pass (not too familiar with typescript)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead of using unknown you could use JsonValue or any (JsonValue would be more specific)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JsonValue works! Thanks!

*/
async updateOrganizationMetadata(
id: string,
data: Record<string, Any>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, we should take in a record of string to lowercase any (the typescript type), and then convert that into a pb.Struct so that it's easier for the user to use

Copy link
Member

@edobranov edobranov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(left one comment that I want to make sure we're clear on, otherwise nothing that's blocking from me)

Copy link
Member

@njooma njooma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to pull from main and regenerate the protos (using make build-buf) because it looks like your branch is still using the map<string, Any> proto definition rather than the Struct one

* @returns A record whose keys match `data`,
* with values unpacked from Struct messages
*/
export const decodeMetadataMap = (data: Record<string, Any>): Record<string, JsonValue> => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still needed? I don't believe we're using protobuf.Any anywhere now

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope! thanks for clarifying

id: string
): Promise<Record<string, JsonValue>> {
const response = await this.client.getOrganizationMetadata({ organizationId: id });
return decodeMetadataMap(response.data);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should just be able to return response.data.toJson(), no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, that basically works - needed to convert it to Record<string, JsonValue>

Comment on lines 1226 to 1229
const convertedData = new Struct({ fields: {} });
for (const [key, val] of Object.entries(data)) {
convertedData.fields[key] = Value.fromJson(val);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similarly, i don't think you have to convert any fields, just use Struct.fromJson(...)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, thanks!

Copy link
Member

@edobranov edobranov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM % a couple docstring tweaks

Comment on lines 1286 to 1288
* Updates user-defined metadata for a machine robot.
*
* @param id The ID of the machine robot
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Updates user-defined metadata for a machine robot.
*
* @param id The ID of the machine robot
* Updates user-defined metadata for a robot part.
*
* @param id The ID of the robot part

* Retrieves user-defined metadata for an organization.
*
* @param id The ID of the organization
* @returns The metadata associated with the organization as a plain JS object
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @returns The metadata associated with the organization as a plain JS object
* @returns The metadata associated with the organization

The other docstrings don't mention this so I think we can remove it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for calling this out!

Copy link
Member

@njooma njooma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!! Thanks for all the updates.

For future reference, you could also do something like this so that you aren't doing the same cast over and over again:

return (response.data?.toJson() as JsonObject) ?? {};

@JosephBorodach JosephBorodach merged commit 35c99e0 into main Mar 12, 2025
3 checks passed
@JosephBorodach JosephBorodach deleted the RSDK-10123 branch March 12, 2025 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants