Related to the consent bug that popped up because of attribute value order changing, I'm wondering if the problem/cause of this was the use of Streams in the setValues method.
I know it says the stream is sequential, but I wonder if the collector isn't.
We could probably reproduce this in unit testing, maybe, but either way since this is purely a syntax thing, I think we might want to unroll that back into a loop and ensure we don't change the order inadvertently.
This isn't because of consent, but if this happened in a DataConnector, you'd be in very big trouble. In fact, I do that and I'm wondering why I don't see the problem, so I'll dig a bit more, but I am concerned.
With a multi-attribute result set, it's fatal if each individual one has its values reordered, whereas the only obvious problem with the single Attribute case is consent.
Related to the consent bug that popped up because of attribute value order changing, I'm wondering if the problem/cause of this was the use of Streams in the setValues method.
I know it says the stream is sequential, but I wonder if the collector isn't.
We could probably reproduce this in unit testing, maybe, but either way since this is purely a syntax thing, I think we might want to unroll that back into a loop and ensure we don't change the order inadvertently.
This isn't because of consent, but if this happened in a DataConnector, you'd be in very big trouble. In fact, I do that and I'm wondering why I don't see the problem, so I'll dig a bit more, but I am concerned.
With a multi-attribute result set, it's fatal if each individual one has its values reordered, whereas the only obvious problem with the single Attribute case is consent.