acually postoverflow _before_ reprocessing #1739
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
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 fixes postoverflow behaviour.
In fact actually reprocessing event is done before postoverflow. So if event go through both reprocessing and postoverflow, it gets reprocessed without the postoverflow enrichement. Hence in practice this leads to enforce our users to make a choice between postorverflow and reprocessing. Having some enrichment at postoverflow time can be handy to process through a new scenario.
Making it get through postoverflow before reprocessing will allow the event to get enriched before getting reprocessed. This will allow more flexible postoverflow and reprocessing stuff for users.
As for the impact, this reprocessing stuff is only used in the ban-defcon-drop-range scenario, which is not impacted by this change.