-
Notifications
You must be signed in to change notification settings - Fork 43
Description
Problem
Using the retest ID as a locator is currently only possible if a GM exists. It would be helpful if it could also be used without a GM, which requires RetestIdProvider to be deterministic.
Solution
@roesslerj proposed a draft via #563, but this still needs some work. Quote from my comment:
Having a deterministic
RetestIdProvideris not a contract to my knowledge, so we cannot rely on this. For example, we still shipRandomSuffixRetestIdProviderand the user is free to provide a custom implementation. Then this doesn't work.If we want
RetestIdProviders to be deterministic in general, we have to document and require this contract (like e.g.equalsrequires an equivalence relation), otherwise there will be undefined behavior.Also, what happens if slight state changes lead to different counts? We no longer lookup the element in the old state and do a 1-on-1 assignment, instead we select it solely on the basis of the retest ID I guess?
It would rather mark this as a draft. We have to discuss the determinism and we need proper tests, at least for the aforementioned situations. If we do such a "drastic" change without tests, and no existing tests are failing, we are doing something wrong.