Skip to content

Conversation

@seanavery
Copy link
Member

@seanavery seanavery commented Nov 22, 2024

Description

This PR adds a few helpers to interact with dynamic resolution stream server endpoints.

Tests

Added success and failure test cases for the new stream interface methods.

@seanavery seanavery requested a review from a team as a code owner November 22, 2024 19:49
@seanavery seanavery requested review from jckras and stuqdog November 22, 2024 19:49
@seanavery seanavery changed the title [RSDK-9251] - Add stream options helpers to stream client [RSDK-9251] - Add options helpers to stream client Nov 22, 2024
@seanavery
Copy link
Member Author

It looks like the npm check is returning 1 in CI... Would it be ok to bump these dependencies?

> @viamrobotics/[email protected] check
> npm-check --production --ignore=@bufbuild/protobuf

- Checking for unused packages. --skip-unused if you don't want this.
- Checking npm registries for updated packages.

@connectrpc/connect       😎  MAJOR UP  Major update available. https://github.com/connectrpc/connect-es#readme
                                       npm install @connectrpc/[email protected] --save to go from 1.6.1 to 2.0.0

@connectrpc/connect-web   😎  MAJOR UP  Major update available. https://github.com/connectrpc/connect-es#readme
                                       npm install @connectrpc/[email protected] --save to go from 1.6.1 to 2.0.0

Use npm-check -u for interactive update.
make: *** [Makefile:34: lint] Error 1

@seanavery seanavery requested a review from randhid November 22, 2024 20:12
@randhid randhid removed their request for review November 23, 2024 01:42
@stuqdog
Copy link
Member

stuqdog commented Nov 25, 2024

@seanavery I think bumping package versions should be fine provided nothing breaks when we do so. If tests start failing otherwise then we'll want to revisit of course.

Copy link
Member

@jckras jckras left a comment

Choose a reason for hiding this comment

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

LGTM. One thing I’m wondering is whether we should add validation for input parameters across the methods (ex: resourceName/name should be non-empty strings, width/height in setOptions should be positive numbers) other than that just left a few questions for my own understanding

const response = await this.client.getStreamOptions(request);
return response.resolutions;
} catch {
return [];
Copy link
Member

Choose a reason for hiding this comment

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

Why return an empty list when the available resolution is not available and not an error message?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah good question! I toyed around with erroring out in the failure case but thought it would be nicer to just return empty array to avoid complexity when calling it in the frontend and trying to fill a dropdown or such with the return. (This is presumptuous as I do not have that much experience with frontend stuff) Happy to change the behavior to throw if that is better.

Copy link
Member

@jckras jckras Nov 25, 2024

Choose a reason for hiding this comment

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

I think simple is better! and would just keep how it is

* @param height - The height of the resolution.
*/
async setOptions(name: string, width: number, height: number) {
const request = new SetStreamOptionsRequest({
Copy link
Member

Choose a reason for hiding this comment

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

do we need any error checking that the width/height parameters are set within a specific bound?

Copy link
Member Author

@seanavery seanavery Nov 25, 2024

Choose a reason for hiding this comment

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

All of the GRPC field checks happen in the server endpoint and it should hopefully error out here with the correct message. Would it be good to add additional checks here in the client before sending?

Copy link
Member

Choose a reason for hiding this comment

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

ah got it. if the checks are happening elsewhere then we def don't need to duplicate it

try {
await this.client.setStreamOptions(request);
} catch {
// Try again with just the resource name
Copy link
Member

Choose a reason for hiding this comment

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

why do we try again with just the resource name? if getValidSDPTrackName(name) is false then we are just falling back to using an unformatted name?

Copy link
Member Author

@seanavery seanavery Nov 25, 2024

Choose a reason for hiding this comment

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

Not sure... Was initially thrown off by this but this is the behavior from the other stream client methods so I copied it. If we want I can do a follow up PR to test this out and remove across the stream client if we dont need 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.

Copy link
Member

Choose a reason for hiding this comment

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

Unfortunately I don't know enough on whether one way is better than another here but I think stick with consistency here on the other stream clients?

@seanavery
Copy link
Member Author

seanavery commented Nov 25, 2024

@stuqdog I unsuccessfully attempted bump on connectrpc dependencies, this caused a dependency conflict on protobuf, so needed to bump both.

    "@bufbuild/protobuf": "^2.2.0",
    "@connectrpc/connect": "^2.0.0",
    "@connectrpc/connect-web": "^2.0.0",

Immediately getting errors from API change when trying to make clean then make build

It appears to be an issue with how the buff binary is generating the protobuf js code.
I attempted to bump to latest "@bufbuild/buf": "^1.47.2", but sill having the issue with proto3.

> vite build

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.
vite v5.4.8 building for production...
✓ 308 modules transformed.
x Build failed in 263ms
error during build:
src/gen/common/v1/common_pb.js (8:24): "proto3" is not exported by "node_modules/@bufbuild/protobuf/dist/esm/index.js", imported by "src/gen/common/v1/common_pb.js".
file: /Users/sean/viam-typescript-sdk/src/gen/common/v1/common_pb.js:8:24

 6: // @ts-nocheck
 7: 
 8: import { MethodOptions, proto3, Struct, Timestamp, Value } from "@bufbuild/protobuf";
                            ^
 9: 
10: /**

    at getRollupError (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/parseAst.js:392:41)
    at error (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/parseAst.js:388:42)
    at Module.error (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:14844:16)
    at Module.traceVariable (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:15291:29)
    at ModuleScope.findVariable (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:13192:39)
    at MemberExpression.bind (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:6860:49)
    at CallExpression.bind (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:2836:23)
    at CallExpression.bind (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:11148:15)
    at VariableDeclarator.bind (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:2836:23)
    at VariableDeclaration.bind (file:///Users/sean/viam-typescript-sdk/node_modules/rollup/dist/es/shared/node-entry.js:2832:28)
make: *** [build-js] Error 1

Is it ok to merge a PR with a ❌ test? Happy to create a ticket for this with results from my bump attempt.

npm run lint
npm run typecheck
npm run check -- --ignore=@bufbuild/protobuf
npm run check -- --reject="@bufbuild/protobuf,@connectrpc/connect,@connectrpc/connect-web"
Copy link
Member Author

Choose a reason for hiding this comment

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

@stuqdog Added connectrpc to ignore list since they also depend on protobuf. Is this ok?

"build:types": "tsc --project tsconfig.build.json",
"build:copy-dts": "copyfiles -u 1 \"src/gen/**/*.d.ts\" dist",
"check": "npm-check --production",
"check": "ncu --errorLevel 2 --dep prod",
Copy link
Member Author

Choose a reason for hiding this comment

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

Had to move away from npm-check since it apparently cannot handle the scope level @ properly inside an ignore list.

@seanavery seanavery merged commit 76d58dd into viamrobotics:main Nov 26, 2024
3 checks passed
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.

3 participants