Skip to content
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

Messages from User Feedback shouldn't be dropped by quotas and rate limits!! #71017

Closed
ebelair opened this issue May 16, 2024 · 5 comments
Closed

Comments

@ebelair
Copy link

ebelair commented May 16, 2024

Problem Statement

Yes, quotas and rate limits are important to manage noisy projects, but...

With this User Feedback feature, we should make sure that those errors always go through. If a specific user has taken their time to write a note, and send it our way... It's kinda sad to see it capped out at the source...! 😞

Otherwise there would need to be a way to turn off feedback collection if we already know it's not likely to go through... Just to be respectful of our users' time, and not ask them for feedback if it's about to be trashed immediately anyway 🧠➡️🗑️

Solution Brainstorm

I think we should either:

  • Count User Feedback entries as a separate quota in different Sentry plans, -or-
  • Just make sure to prioritize entries with User Feedback attached over anything else (rate limits and all)

Product Area

User Feedback

@getsantry
Copy link
Contributor

getsantry bot commented May 16, 2024

Assigning to @getsentry/support for routing ⏲️

@getsantry
Copy link
Contributor

getsantry bot commented May 20, 2024

Routing to @getsentry/product-owners-user-feedback for triage ⏲️

@ryan953
Copy link
Member

ryan953 commented May 21, 2024

@ebelair Thanks for the feedback!

It sounds like you're worried that a user might spend all this time to write a message, and you point out how it would be terrible if that message got dropped due to quota or something like that.

Well good news... there's no quota for user submitted feedback! 

We do have sampleRate for regular errors but there is no equivalent for feedback messages.

The idea is that we don't need to put quota on this, and we're not charging for it. Here's some of the philosophy:

  • User feedback is a much lower volume than errors. Someone has to open it up and type something out, so it's not that much load.
  • User feedback can be much higher signal. If a user has explained something well it can be worth 100's of errors to read the message instead.
  • User feedback could be related to something that doesn't throw an error. You might not have any other way of finding out about the problem.
  • Also, we were kind of thinking that if someone's site is a mess, their quota is consumed... at least user feedback should work. This way their most engaged users can stay in touch and help get things back on track.

That doesn't mean that everything is without quota. Errors are Replays are submitted before the feedback, so quota will be used even before the user starts to type out their message. Also the screenshot feature is built on top of our attachments infrastructure which should have sufficient space on all plans for 100's or 1000's of images per month, depending on the screen size of users.

@ryan953
Copy link
Member

ryan953 commented May 21, 2024

If you've got more questions lmk, otherwise you will be able to see every feedback that hits our servers!

@ryan953 ryan953 closed this as completed May 21, 2024
@ebelair
Copy link
Author

ebelair commented May 21, 2024

@ryan953 Thanks for replying!

Unfortunately, what you're saying does not seem to be the case. Our account was maxed out on errors and we were unable to see User Feedback come through... and as soon as we provisioned more errors, it started getting in again.

I reached out to customer support and they thought this happened as intended – if you want to follow-up, our support case was no. 121621.

Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

3 participants