You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Having a deterministic RetestIdProvider is not a contract to my knowledge, so we cannot rely on this. For example, we still ship RandomSuffixRetestIdProvider and 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. equals requires 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.
The text was updated successfully, but these errors were encountered:
This has been partly addressed with #612, where it for now tries to find a retest ID, if no Golden Master has been created yet. This implementation is similar (if not equal) to the originally proposed solution and does no assumptions or semi-intelligent lookups. It simply queries the soon-to-be-persisted state for the retest ID instead of loading the previous one. Therefore it is the users responsibility to ensure that the retest ID is present.
Since then, I have documented the generation in more detail, but we should document this specific feature with its effects more thoroughly before release (e.g. that the default implementation is in fact deterministic).
Of course, the use cases are fairly limited, when not precisely knowing how the active RetestIdProvider generates the IDs. In such a case it would only come down to regenerating Golden Masters (assuming none of the queried attributes has changed, e.g. tag).
I will keep this open, until the feature has been documented. However, feel free to create more issues regarding your other points.
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:
The text was updated successfully, but these errors were encountered: