Repository navigation
fix(code-interpreter): use backend timestamp in JS OutputMessage - #2077
Conversation
## Summary The JS Code Interpreter's `parseOutput` set `OutputMessage.timestamp` to `new Date().getTime() * 1000` — the **client-side clock in microseconds** — ignoring the `timestamp` field the kernel sends with every stdout/stderr message. This diverged from Python (which uses the backend `data["timestamp"]` directly) and from the documented contract (`OutputMessage.timestamp` is described as "Unix epoch in nanoseconds"). The JS value was from the wrong clock *and* the wrong unit. Fix: read `msg.timestamp` in the stdout and stderr branches of `parseOutput`. The type stays `number` (unchanged), matching the Python reference implementation and the documented nanosecond contract. JS-only — Python is already correct. Closes #1969. ## Why this is a real bug (not a pseudo-gap) - Python reads `data["timestamp"]` with no fallback, so the kernel always sends `timestamp`; JS reads `msg.text` from the same message but dropped `msg.timestamp`. - Reproduces with no sandbox/API key: feeding `parseOutput` a stdout message with `timestamp: 1700000000000000000` yields `~1791599674953000` (`Date.now()*1000`), not the backend value. ## Verification ```bash cd packages/code-interpreter-js pnpm vitest run tests/messaging.test.ts # 4 passed (2 existing + 2 new) pnpm run lint # no new warnings pnpm run typecheck # passes ``` New tests assert `OutputMessage.timestamp` equals the backend `msg.timestamp` for both stdout and stderr (construct an `Execution`, feed `parseOutput` a JSON line with a fixed `timestamp`, assert the captured message carries it through). ## Usage example ```ts import { Sandbox } from '@e2b/code-interpreter' const sandbox = await Sandbox.create() await sandbox.runCode('print("hello")', { onStdout: (msg) => { // Before: msg.timestamp was Date.now()*1000 (client clock, microseconds) // After: msg.timestamp is the kernel's Unix-epoch nanosecond timestamp console.log(msg.line, msg.timestamp) }, }) ``` ## Changeset `@e2b/code-interpreter` **patch** — `OutputMessage.timestamp` now reflects the backend timestamp instead of the client clock. Type unchanged (`number`), so no breaking change. Co-authored-by: lemonzoey <25550414+lemonzoey@users.noreply.github.com>
|
I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".
|
🦋 Changeset detectedLatest commit: 6129dd3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
TASTE.md review: complies — no violations found (checked T-1 parity, T-27 streaming callbacks, T-52 backend as source of truth, T-54/T-69 public surface & docs); the change brings JS OutputMessage.timestamp in line with the Python SDK and the documented nanosecond contract.
Package ArtifactsBuilt from dbb71dd. Download artifacts from this workflow run. JS SDK ( npm install ./e2b-dockerfile-utils-0.1.2-devin-1793633113-accept-pr-1970.0.tgz ./e2b-2.62.1-devin-1793633113-accept-pr-1970.0.tgzCLI ( npm install ./e2b-cli-2.23.1-devin-1793633113-accept-pr-1970.0.tgzCode Interpreter JS SDK ( npm install ./e2b-code-interpreter-2.9.1-devin-1793633113-accept-pr-1970.0.tgzDesktop JS SDK ( npm install ./e2b-desktop-2.5.1-devin-1793633113-accept-pr-1970.0.tgzPython SDK ( pip install ./e2b_dockerfile_utils-0.1.1+devin.1793633113.accept.pr.1970-py3-none-any.whl ./e2b-2.62.0+devin.1793633113.accept.pr.1970-py3-none-any.whlCode Interpreter Python SDK ( pip install ./e2b_code_interpreter-2.11.6+devin.1793633113.accept.pr.1970-py3-none-any.whlDesktop Python SDK ( pip install ./e2b_desktop-2.7.2+devin.1793633113.accept.pr.1970-py3-none-any.whl |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
… in JS OutputMessage Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Summary
Lands community PR #1970 by @lemonzoey (squash-merged into this branch) onto
main. Closes #1969.The JS Code Interpreter's
parseOutputsetOutputMessage.timestampto the client clock in microseconds, ignoring the kernel-providedtimestamp. Python already uses the backend value, and the documented contract is Unix epoch nanoseconds.Applied to both the stdout and stderr branches in
packages/code-interpreter-js/src/messaging.ts. Type staysnumber. Includes a@e2b/code-interpreterpatch changeset.Precision: nanosecond epochs (~1.7e18) exceed
Number.MAX_SAFE_INTEGER, so the JS value is only precise to multiples of 256 ns. Python keeps the exactint. This limit is documented onOutputMessage.timestampand in the changeset. Tests intests/messaging.test.tsparse raw JSON lines with a realistic non-multiple-of-256 value and check the rounding.Usage example
Link to Devin session: https://app.devin.ai/sessions/e37c31685ac645f785744678cd18146e
Open in Devin Desktop: https://app.devin.ai/desktop/session/e37c31685ac645f785744678cd18146e?variant=devin