8000 fix(type): :pencil2: breadcrumbs support timestamp as string by cadesalaberry · Pull Request #11119 · getsentry/sentry-javascript · GitHub
[go: up one dir, main page]

Skip to content
Dismiss alert

fix(type): ✏️ breadcrumbs support timestamp as string #11119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

cadesalaberry
Copy link
Contributor
@cadesalaberry cadesalaberry commented Mar 15, 2024

The format is either a string as defined in RFC 3339 or a numeric (integer or float) value representing the number of seconds that have elapsed since the Unixepoch.

When browsing the documentation, I realised, that the sentry server accepts both number and string for the timestamp. I updated the type to reflect this change. I am not sure the non-breadcrumbs timestamp also supported string, so I made sure to turn it into a number whenever it was needed. I added JSDoc to avoid back and forth with the web documentation (which I had trouble finding initially).

I added a test covering the timestamp in the breadcrumb sent as a string and also converted to a number when needed.

In my codebase I ended up ignoring the typing and it kept working:

scope.addBreadcrumb({
  type: 'debug',
  category: 'opentok.signal',
  // FIX-ME: Sentry supports timestamps as strings https://github.com/getsentry/sentry-javascript/pull/11119
  timestamp: new Date().toISOString() as unknown as number,
  message,
}

Before submitting a pull request, please take a look at our Contributing guidelines and verify:

  • If you've added code that should be tested, please add tests.
  • Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

@cadesalaberry cadesalaberry force-pushed the docs/update-breadcrumb-timestamp-type branch 2 times, most recently from 2d5bee0 to 424b53e Compare March 15, 2024 11:47
Copy link
Member
@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

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

Hey @cadesalaberry thanks for opening this PR!

Please update the PR description that outlines the problem and how you fixed it. This makes it easier for us to review.

Thanks for updating the JSDocs :)

Comment on lines 6 to 8

PS: remember to install the following extension on VSCode to run the tests:
https://marketplace.visualstudio.com/items?itemName=augustocdias.tasks-shell-input
Copy link
Member

Choose a reason for hiding this comment

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

I don't see much reason to tell people to download this extension. Running the yarn commands above in the terminal is probably easier.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed. I realised it was already part of the recommended extensions in .vscode. I'll remove this comment.
The main modification in this file is adding the yarn build, which took me some time to understand.

@cadesalaberry cadesalaberry force-pushed the docs/update-breadcrumb-timestamp-type branch from abc97fe to ea23672 Compare March 15, 2024 16:07
@cadesalaberry
Copy link
Contributor Author

@Lms24 do you need anything else?

Copy link
Member
@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

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

Thanks for updating the description! I'm still a bit hesitant to merge this because I'm not sure if there's a good reason to widen the timestamp type. The reason is that this is a breaking change, which would generally fine since we're currently working on our major, but should still be justified.

You're right, our ingestion backend supports sending string timestamps. However, SDKs don't have to support sending timestamps in all varieties. It's generally fine, if we just send timestamps as a number.

Therefore my question: Is there a reason why you prefer setting the timestamp as a string? More specifically, in your code example, why not use new Date().getTime() / 1000 instead?

@cadesalaberry
Copy link
Contributor Author
cadesalaberry commented Mar 18, 2024

It made sense for me at the time. I see 3 reasons to do it:

  • ISO strings are readable by humans, epoch are not
  • It makes the Sentry agent and the backend follow a consistent API
  • It avoids the "is it seconds or milliseconds" logic

What triggered my PR was seeing this error on Sentry:

Sentry has identified the following problems for you to monitor

Name	breadcrumbs.values.98.timestamp
Reason	timestamp out of range
Value	1710348352188
Name	breadcrumbs.values.99.timestamp
Reason	timestamp out of range
Value	1710348352204

I see your point, new Date().getTime() / 1000 would definitely do the job, and handling a single type makes the code simpler. However, I don't understand how type widening makes it a breaking change, all previous implementations would still be working without changes.

Feel free to close the PR if it does not fit the vision! The changes in .github/PULL_REQUEST_TEMPLATE.md might deserve to be merged in another quick PR of yours though 😄

Lms24 pushed a commit that referenced this pull request Apr 9, 2024
When interacting with the Breadcrumd API, I had some trouble finding the
correct documentation. I retrieved my changes for the previous
[PR](#11119) to make
sure the JSDoc is updated with the actual doc.
@cadesalaberry cadesalaberry force-pushed the docs/update-breadcrumb-timestamp-type branch 3 times, most recently from ac72290 to 72b1a67 Compare April 19, 2024 14:48
cadesalaberry added a commit to cadesalaberry/sentry-javascript that referenced this pull request Apr 19, 2024
When interacting with the Breadcrumd API, I had some trouble finding the
correct documentation. I retrieved my changes for the previous
[PR](getsentry#11119) to make
sure the JSDoc is updated with the actual doc.
@cadesalaberry cadesalaberry force-pushed the docs/update-breadcrumb-timestamp-type branch from 72b1a67 to b9a0a07 Compare April 19, 2024 15:02
@mydea
Copy link
Member
mydea commented Jul 2, 2024

Hey, thank you for opening this PR. In the meanwhile, v8 landed, and we will for now not widen the API like this, as it increases bundle size and complexity. We may revisit this in the future. Still, thank you for your contribution - we really appreciate it!

@mydea mydea closed this Jul 2, 2024
@cadesalaberry cadesalaberry deleted the docs/update-breadcrumb-timestamp-type branch July 27, 2024 22:16
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
0