feat: Add generic modal for requesting access to private gaming repository

[priscilawebdev]

Note
The idea is to replace PlayStationSdkAccessModal after this is merged

closes https://linear.app/getsentry/issue/TET-921/collect-github-handle

Screen.Recording.2025-07-24.at.10.08.56.mov

[linear]

TET-921 Collect Github handle

[cursor]

Bug: Feedback Formatting and Submission State Issues

The PrivateGamingSdkAccessModal has two issues:

1. The feedback message sent via captureFeedback inconsistently formats gaming platform names: single platforms use raw values (e.g., 'playstation'), while multiple platforms use display labels (e.g., 'PlayStation'), resulting in inconsistent capitalization.
2. If the captureFeedback call fails, the isSubmitting state is not reset and the modal remains open, leaving the UI in a perpetual submitting state.

Locations (1)

• static/app/components/modals/privateGamingSdkAccessModal.tsx#L49-L107

Fix in Cursor • Fix in Web

[cursor]

Bug: Feedback Submission Timing and Formatting Issues

The captureFeedback function is asynchronous but not awaited, leading to premature isSubmitting state reset, early success message display, and modal closure before feedback is sent. Additionally, the feedback message inconsistently formats gaming platform names, using raw values for single selections and human-readable labels for multiple selections.

Locations (1)

• static/app/components/modals/privateGamingSdkAccessModal.tsx#L54-L107

Fix in Cursor • Fix in Web

[TkDodo]

this function is unused, so I’d expect knip to complain here (which it doesn’t). I’ll look into that, but can we make the function used somewhere?

[priscilawebdev]

yes it did not complain which is weird, but this function will be used in 3 different places. Examples: #96300 and #96415

[TkDodo]

can we please not wrap every function we create in useCallback 🙏 . There is absolutely no need here, because:

• it’s only passed to the click handler of a Button, which doesn’t care about referential stability.
• it is dependent on onSubmit, which is a prop, which is always an inline function, so the useCallback has to run every time anyways.

All it does in this instance is add more code and complexity and mental overhead.

[priscilawebdev]

hey thanks! it is not always super clear when we should use useCallback, and I noticed we've been applying it by default whenever we define a function in our codebase. This one for example was copied and pasted from here.

I was wondering...do we have a linter or any tooling that could help us identify when useCallback is actually necessary? That would be super helpful!

[TkDodo]

I’m unsure how this should work. This handleSubmit function is a synchronous callback, so it first calls setIsSubmitting(true) followed by setIsSubmitting(false), so I don’t see where the true state would ever be rendered 🤔 .

This is part of the reason why merging something that has no usage is a bit counter productive imo because we can’t know how it works / what it does.

I’m guessing onSubmit is going to maybe trigger a mutation on the call-side? Would it be better to trigger that mutation from inside here, which would also give us mutation state like isPending and callbacks to add the success messages properly?

[priscilawebdev]

I agree - it would be great to use isPending and show a success message only if everything went well. But we're using captureFeedback, which doesn't wait for the result. It just tries to send the feedback and returns immediately. You can read more about it here.

This modal will be removed in a future phase, but for now, we’re keeping it simple by reusing what we already have.