-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
feat(feedback): Add captureFeedback
method
#11428
Conversation
size-limit report 📦
|
dfab71c
to
abf402e
Compare
Feel free to merge #11626 into this PR if it makes sense; otherwise we can also merge sequentially :) |
abf402e
to
c16b325
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for the tests
import { getLocationHref } from '@sentry/utils'; | ||
import { FEEDBACK_API_SOURCE, FEEDBACK_WIDGET_SOURCE } from '../constants'; | ||
import { prepareFeedbackEvent } from '../util/prepareFeedbackEvent'; | ||
import { FEEDBACK_API_SOURCE } from '../constants'; | ||
|
||
/** | ||
* Public API to send a Feedback item to Sentry | ||
*/ | ||
export const sendFeedback: SendFeedback = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't have to be in this PR, but should we continue to export this publicly? Or just leave it as an internal helper for our own UI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a good question, I don't have a strong feeling there! I think for backwards compatibility we might as well continue to export it, but I'll defer to whatever you folks think about this 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think with the new captureFeedback()
being a thing, this isn't too important for people anymore. If we were going to remove it now would be a fine time.
It seems like if we keep it, then the docs will be something like:
There is
captureFeedback()
, and alsosendFeedback()
... the differences are....
OR if we remove it, docs could instead mention:
There is
captureFeedback()
. You can response by doing something likeclient.on('afterSendEvent', (event, response) => ...)
and check thatevent.event_id === eventId
I'm starting a migration doc to track moving from "feedback beta & v7" into "v8 & GA", so this could fit there too.
#11731
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove the public export then in a follow up PR 👍
packages/core/src/feedback.ts
Outdated
// For now, we have to send attachments manually in a separate envelope | ||
// Because we do not support attachments in the feedback envelope | ||
// Once the Sentry API properly supports this, we can get rid of this and send it through the event envelope | ||
if (client && transport && dsn && attachments && attachments.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cmanallen @aliu3ntry Is this still true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can send whatever you want in an envelope. You're just capped to three items. At least, as far as I know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Andrew has a PR up but it's not merged yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes..I opened a relay PR to handle this that's still a work in progress
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused on how that PR solves the problem? Are you trying to put attachments into the feedback envelope item? Or are you trying to send attachments in the same envelope with a feedback item? These are two different problems.
Let's talk about this on Monday before my PTO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed this with Andrew, but we want to send attachments in the same envelope as the feedback, the attachment will be its own item. We want to use getCurrentScope().addAttachment()
to add the attachment to the envelope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, to clarify: This means I will remove the code to add attachments to a separate envelope, and also remove the attachments
option for the method, instead expecting this to be added to the scope the same way as for any other event? --> This will reduce bundle size and complexity here too, because this should be handled OOTB by captureEvent
so this should "just work" really.
This is OK and will work (with up-to-date self-hosted, at least) today?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like https://github.com/getsentry/team-replay/issues/393 hasn't landed yet; but @mydea the SDK should send attachments and feedback together IMO.
Why?
- Sending them in the same payload gives us better guarantees that both parts made it successfully, so we won't get into cases where random attachments are ingested, but no matching feedback exists.
- We'll save a bunch of SDK code
- We can take advantage of being in alpha & beta state for the screenshot feature specifically.... I think it's ok to have a higher min-requirement on the server because turning on screenshots is opt-in right now.
For example, in the docs we could say something like (this is the idea, not the verbatim docs i'd write):
v8 of the Feedback SDK supports allowing users to include a screenshot with their feedback submission.
On-Prem users must update to version ${after getsentry/team-replay#393 lands} before enablingshowScreenshot: true
in the SDK config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree that this makes sense, we just need to know how long it will take to land this and when it will be on-prem, and decide if we want to hold off on merging this until we know this!
a9b30eb
to
743ab6d
Compare
So I updated this to send attachments in the same envelope! Makes everything easier. Sentry.captureFeedback({ message: 'xx' }, { attachments: [attachment1] }); Same as with all other capture methods. |
743ab6d
to
56fe6e5
Compare
The change on ingest to accept feedback and attachments on the same envelope was done through: This change has been live on SaaS and made it to self hosted: 24.4.2 |
}); | ||
|
||
if (client.emit) { | ||
client.emit('beforeSendFeedback', feedbackEvent, { includeReplay: Boolean(includeReplay) }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we still want to have this beforeSendFeedback hook. This should a) start to capture any buffered replay b) add a breadcrumb to the replay
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Long term it'd be better to move into the Actor::onClick event, so we get more replay before they start typing, but that should be a followup because of the quota impact
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do still emit this, but in captureFeedback
;)
Assuming this PR sends feedback+attach in same envelope, let me know before you merge so I can turn on the ingest FF! I'ts only set in s4s right now.
|
…on (#3617) Follow up after getsentry/team-replay#393. We've set the option to true for all regions and tested that it works, so this is a dead code path we can remove Relates to getsentry/sentry-javascript#11428 #skip-changelog
This PR adds a new
captureFeedback
method which is exported from all SDKs.This method can be used to capture a (new) user feedback from any package.
We follow the same semantics as for other capture methods like
captureException()
orcaptureMessage()
: The method returns a string, which is the event id. We do not wait for sending to be successful or not, we just try to send it and return. You can both set anassociatedEventId
(which replaces the event_id of the "old"captureUserFeedback
), and also pass attachments to send along (which for now are sent as a separate envelope).For usage in the modal UI, there is still
sendFeedback
which continues to return a promise that resolves with the event ID, or rejects with a meaningful error message if sending fails.This also deprecates
captureUserFeedback()
, which is only exported in browser. We cannot remove this yet becausecaptureFeedback
will only work on newer self-hosted instances, so not all users can easily update. We can/should remove this in v9.Includes #11626
Fixes 49946