feat(ts-sdk): align TypeScript SDK with Python SDK

[xdlkc]

Summary

Align TypeScript SDK with Python SDK, achieving feature parity across 8 modules.

Changes

New modules (50+ files, 400+ tests)

• bench/: Harbor benchmark configuration models - 16 files, 115 tests
• job/: Job/Trial execution system (JobExecutor, Operator, BashTrial, HarborTrial, ComposeTrial) - 28 files, 143 tests
• envhub/datasets/: Dataset client and OSS registry - 8 files, 55 tests
• model/server/: Express-based LLM model server with SSE streaming - 10 files, 81 tests
• sandbox/speedup/: Strategy-pattern speedup executor (Apt/Pip/Github strategies)
• sandbox/oss_client.ts: Standalone OSS client extracted from Sandbox class

Enhanced modules

• sandbox/client.ts: Added delete(), restart(), commit(), attach() methods
• sandbox/agent/: RockAgent full implementation with RuntimeEnv, ModelService, and Deploy integration (YAML config loading, pre/post init flow)

Verification

• 66 test suites, 843 tests, 0 failures
• TypeScript compilation: 0 new errors

Python → TypeScript pattern mapping

• Pydantic → Zod (superRefine/transform for cross-field validators)
• asyncio → Promise/async-await
• FastAPI → Express
• TYPE_CHECKING → import type

Design document

See docs/ts-python-sdk-alignment-plan.md for the complete gap analysis and implementation plan.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ xdlkc
❌ sa-buc

---

sa-buc seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Timandes]

Code review: Request Changes

I reviewed this PR against base e886932a770e8f44fab5217a76e6ca04c56a8129, focusing on the newly added TypeScript SDK execution paths. I think this should not merge yet because several user-facing paths can report success without doing the intended work.

Blocking issues

1. Job execution is currently a stub and can return false success

   rock/ts-sdk/src/job/executor.ts

   _doSubmit() only returns { sandbox: null, pid: 0, trial }; it does not create/start a sandbox, call trial.onSandboxReady(), run trial.setup(), write the generated script, or start a nohup process. wait() then calls trial.collect(undefined, "", 0), so new Job(config).run() can report a completed job even though the user script never ran.

   Please port the real lifecycle from the Python JobExecutor (Sandbox(config.environment), sandbox.start(), session creation, script upload, start_nohup_process, and wait/collect), and avoid swallowing submit/collect failures as successful empty results.

2. Compose init container script generation is broken

   rock/ts-sdk/src/job/compose/script_builder.ts

   _sectionInitContainers() appends a docker run ... command, then appends if ! ( LAST_COMMAND ); then, and later only replaces the first ( LAST_COMMAND ) with the last init container command. This means a single init container runs twice, and multiple init containers can leave stale LAST_COMMAND placeholders or check the wrong command.

   Please build one command string per init container and emit only the guarded form, e.g. if ! <that command>; then ... fi, without post-generation placeholder replacement.

3. Job.cancel() calls Sandbox.arun() with the wrong signature

   rock/ts-sdk/src/job/api.ts

   Sandbox.arun() takes (cmd: string, options?: ...), but cancel() passes a single object { cmd, session } and then silently ignores any error. In real use this will fail to kill trial processes and look like a successful best-effort cancellation.

   Please call await sandbox.arun(kill ${tc.pid}, { session: tc.session }) (or the safer equivalent), and do not hide cancellation failures that leave work running.

4. Generated runner shell script interpolates untrusted config values without shell quoting

   rock/ts-sdk/src/job/compose/script_builder.ts

   Values such as oss_artifacts[].target_path, oss_key, name, init container image, and volume mount fields are interpolated directly into bash fragments. Double quotes do not prevent command substitution like $(...), and embedded quotes/spaces can break the script. The TS SDK already has shellQuote() in src/utils/shell.ts; this generator should use it consistently or avoid shell string construction where possible.

Test coverage gap

The added tests mostly assert that objects/strings are produced. They do not exercise real job execution, cancellation, generated runner syntax for multiple init containers, or hostile/special-character config values. Please add regression tests for the issues above before merging.

Non-code blocker

The CLA assistant currently reports a missing CLA signature for this PR, which also needs to be resolved before merge.

[Timandes]

Follow-up review: still Request Changes

Thanks for the update. I re-reviewed the latest head 41bebeb99c88d3418d31cbabe1165ec88ad8d43a.

The previous issues around the stubbed JobExecutor, Job.cancel() arun signature, compose init-container LAST_COMMAND, and shell quoting in the compose runner look addressed. The added tests also cover those paths more directly now.

Remaining blocking issue

Job execution still loses the real script exit code and can report failed jobs as successful

rock/ts-sdk/src/job/executor.ts

_doWait() currently uses the exitCode returned by sandbox.handleNohupOutput() as the trial exit code:

const obs = await client.sandbox.handleNohupOutput(...);
const exitCode = obs.exitCode ?? 1;
const result = await client.trial.collect(client.sandbox as Sandbox, obs.output ?? "", exitCode);

However, the current Sandbox.handleNohupOutput() returns exitCode: 0 whenever waitForProcessCompletion() says the nohup process is no longer alive. That value means the process finished; it does not mean bash <job-script> exited with status 0. A user script containing exit 1 can therefore be collected with exit_code=0 and marked completed.

Please persist and read the actual script exit code, for example by wrapping job execution as something like:

bash <script_path>
echo $? > <prefix>.exit

Then _doWait() should read that sidecar exit-code file and pass the real value into trial.collect(). Alternatively, adjust the nohup wrapper/protocol so handleNohupOutput() can return the child command exit status rather than only the polling status.

The new executor test mocks handleNohupOutput() returning exitCode: 7, so it does not exercise the real Sandbox.handleNohupOutput() behavior and misses this regression. Please add a regression test where the submitted script exits non-zero and the final JobResult is failed with the same exit code.

Non-code blocker

The CLA check is still pending for one committer, so this PR is still blocked on CLA as well.