-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Response context RFC #22
Conversation
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 have a slight preference for Option 2 -- I feel like event.request
itself should be a context and is only a top-level field for historical reasons. I do not have a strong opinion though, both options seem fine to me.
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.
Between Option 1 and Option 2, I would recommend to go with Option 2: Adding a Response
context type in contexts
. This allows us to create typing for known fields, documentation, normalization, and shows up in the UI automatically. When the SDK is used with older self-hosted deployments, this further does not lead to errors showing up in the issue details UI.
Once we've chosen an option, please structure the RFC so that it describes the proposed change and lists alternatives separately.
Co-authored-by: Joris Bayer <jjbayer@gmail.com>
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.
Good to go once the comment on on is_redirect
is resolved. Thank you!
Add
Response
interface that contains information on a HTTP response related to the event.Rendered RFC