derived_tstamp and etl_tstamp should always be defined #80
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.
Previously, this app generated events with undefined
etl_tstamp
andderived_tstamp
, even when enrichments are enabled. This old behaviour was defensible because the purpose of this app is to generate all edge cases of possible events.However, if you look at the Enrich code, it is completely impossible for those timestamps to be null:
etl_tstamp
is set herederived_tstamp
, see these comments to see why it is always set.I think it is reasonable to say a valid enriched event must have non-null
etl_tstamp
andderived_tstamp
. Then this event-generator can be used for testing downstream tooling that depend on those fields.