refactor: Abstracted registering of new aggregators into a Harvester class that is responsible for starting, stopping, updating all registered aggregators. #1994
+751
−812
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.
Description
Sorry for the large PR 😬. This PR removes all the places that are necessary to add certain calls when adding a new aggregator. This introduces a harvester class that is responsible for tracking all aggregators. Then depending on stages in the agent it will start, stop, update, and clear the aggregators. To do that I had to update the signature of every aggregator to pass in the harvester instance because registering of an aggregator is done at the construction via
harvest.add
. Also I added an evaluator config to determine when an aggregator is enabled based on relevant configuration. Previously this was done instartAggregators
and was easy to miss when adding a new aggregator.This achieves 1 part of the making it easier to add a new aggregator for the future. I deferred having a common agent method for enqueuing events to another story. The idea behind that is instead of calling the aggregators directly we will have a generic
agent.addEvent
method that takesid
andevent
andpriority
. So right now it'sIt'd be
This functionality will come next. Then we can add the LLM aggregator with its relevant config(still being discussed what the values for config are).
Lastly, I added some missing coverage or made more direct tests around behaviors as it was very difficult to see where things were being tested.
How to Test
Related Issues
Closes #1981