Uniformize event_ts support on inner events #1052
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… other events The fields used to be called EventTS, but WorkflowStepExecuteEvent was the only event struct with such a field.
This field should always be stored/used as a string according to [1]. This also makes the type more consistent across events. [1] slackhq/slack-api-docs#7 (comment)
abustany
force-pushed
the
add-missing-event-ts-on-inner-events
branch
from
401fadf
to
6361adf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds uniform support for the
event_tsfield on all inner events, fixing #1051 . It includes two breaking changes, but I consider those optional and would be happy with only merging the first commit.The two breaking changes are the following
WorkflowStepExecuteEvent.EventTStoEventTimestamp. I did a "brutal" rename, but if backwards compatibility is an issue we could also investigate keeping both fields and have customMarshalJSON/UnmarshalJSONfunctions, though this also opens weird questions like "what do we do when serializing if both are set?".EventTimestampfields to be strings, and notjson.Number. We're not worried about losing precision here sincejson.Numberis actually a string, but it seems (cf. The value containedmessage_tsin LinkShared event is not only a timestamp #998) that this field had to be switched to a string for couple of events already, and having an inconsistent type here feels a bit weird.