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

What should event.payload["timestamp"] represent? #1769

Closed
glasserc opened this issue Sep 19, 2018 · 2 comments
Closed

What should event.payload["timestamp"] represent? #1769

glasserc opened this issue Sep 19, 2018 · 2 comments

Comments

@glasserc
Copy link
Contributor

Refs #945 and #1731. The documentation describes the timestamp field as representing "the time of the event". However, as far as I can tell, the timestamp field in an event represents a collection timestamp calculated relatively early in the request, before the action that triggered event happened. It doesn't represent the time that the event happens, nor the current last_modified / collection_timestamp of anything reflected in the event.

I think I'd like to change the timestamp key in the payload to correspond to the updated collection timestamp of the (parent_id, collection_id) for which the event was fired.

glasserc added a commit to glasserc/kinto that referenced this issue Sep 19, 2018
Don't re-use old self.timestamp when notifying of event. Instead,
re-compute it fresh.

Fixes Kinto#1769.
@leplatrem
Copy link
Contributor

I would agree with changing that indeed: use the current timestamp before serving the response instead of the one when the request kicks in.

We should still be able to have individual or intermediate timestamps in the impact_records attribute I believe.

More generally, we should tackle #945, the semantics of the «global» fields of an event are wrong.

Note: if someone reads this, the terms collection and records in this issue represents the internal notion of kinto.core, and applies to buckets, groups, collections, records, accounts... in kinto. See #710

@glasserc
Copy link
Contributor Author

Thinking about this further, I think that although #1770 is a valid short-term fix, it feels a little odd for me to bless one specific attribute about the resource as "part of the payload". Maybe the right fix is for the payload to include the model or resource or something so that the recipient of the event can decide what attributes it wants.

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

No branches or pull requests

2 participants