if a configuration message is sent after a task has been initialized, then m_speedAltitudeVsEligibleEntityIds will have the id of the entity appended. The appending will always happen, allowing the same entity to be inserted multiple times. This is then used to calculate task options incorrectly or redundantly.
Another approach would be to use a set instead of a vector. This was not done because it would touch many tasks, some of which use the first element, which a set does not have.
The changes under the configure method are redundant because the configs there are guaranteed to be distinct since they come from the TaskManager. These changes are for completeness.
if a configuration message is sent after a task has been initialized, then m_speedAltitudeVsEligibleEntityIds will have the id of the entity appended. The appending will always happen, allowing the same entity to be inserted multiple times. This is then used to calculate task options incorrectly or redundantly.
Another approach would be to use a set instead of a vector. This was not done because it would touch many tasks, some of which use the first element, which a set does not have.
The changes under the configure method are redundant because the configs there are guaranteed to be distinct since they come from the TaskManager. These changes are for completeness.