Backport of scheduler: annotate tasksUpdated with reason and purge DeepEquals into release/1.5.x #16491
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.
Backport
This PR is auto-generated from #16421 to be assessed for backporting due to the inclusion of the label backport/1.5.x.
The below text is copied from the body of the original PR.
reflect.DeepEqual is not suitable for comparing
Job
structs.By design, it
The use of
reflect.DeepEqual
has been the root of bugs a few times in the past.#14917
#10896
#9330
This PR introduces the
OpaqueMapEquals
helper function as a replacement forDeepEqual
for the specific cases of comparingmap[comparable]interface{}
, which is necessary in cases like opaque plugin config, and envoy configs. Unlike DE, OME exhibits the opposite behavior in the two scenarios above. For other (known) types, implement.Equal
method on structs and compare values directly, or defer to other sensible helpers.The
tasksUpdated
helper has also been modified to return a struct containing the first mis-match of fields triggering a destructive update (as opposed to a simple boolean). Folks tracking down misbehavior now need only to add a log line to understand whytasksUpdated
is (or isn't) triggering updates.Benchmark
before
after
The slowdown is primarily caused by
OpaqueMapEquals
- replacing its implementation withDeepEqual
gets the numbers back down. But these numbers are still negligible and the tradeoff for correctness seems worthwhile.Closes #16290