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

Drop request from event #1731

Open
glasserc opened this issue Aug 10, 2018 · 0 comments
Open

Drop request from event #1731

glasserc opened this issue Aug 10, 2018 · 0 comments
Labels
question stale For marking issues as stale. Labeled issues will be closed soon if label is not removed.

Comments

@glasserc
Copy link
Contributor

This is a follow-up to #945. Right now events are gathered by resource/parent. When this happens, payload becomes essentially meaningless. At best we provide "one of" the payloads that makes sense given the impacted_records. The same is true for request. Why do we need to provide one of these for each event? Under what circumstances does request vary for different impacted_records across events in a request, or within an event group in the same resource/parent? If there are such circumstances, should we move request into each impacted_record? If not, can we stop storing request for each event, since we already have the request when we're processing its events? This is a sincere question -- my inclination is to deprecate payload and request, but I know there are a bunch of places where we fabricate requests for reasons and I haven't thought through the implications of what that means for events (e.g. https://github.com/Kinto/kinto/blob/master/kinto/plugins/default_bucket/__init__.py and https://github.com/Kinto/kinto-signer/blob/master/kinto_signer/utils.py#L171).

@alexcottner alexcottner added the stale For marking issues as stale. Labeled issues will be closed soon if label is not removed. label Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question stale For marking issues as stale. Labeled issues will be closed soon if label is not removed.
Projects
None yet
Development

No branches or pull requests

2 participants