Fix ToGatewayUri after #6823 #6851
Conversation
|
Why add generation number to gateway uris? Especially non-zero gen numbers, as they will be later specifically removed - this ends up costing twice for no gains: 1) get gateway address 2) create siloaddress and get gateway uri with gen 3) parse siloaddress with gateway uri 4) create a new siloaddress with gen 0: steps 2, 3 are entirely useless? |
|
For consistency with existing code. It could be made consistent by removing the generation everywhere, too, but this reverts to the previously known-good behavior. The current code fails the MembershipTable_Azure_Gateway test (my bad for not verifying the result) |
|
But isn't the point of improving code to change the current consistent state to a new consistent state of code? The /gen (or even /0) doesn't provide any value here... |
|
Usually we would revert the entire PR as soon as an issue is found (eg, test failing), and then issue a second PR which fixes those issues in addition to the original changes. If you're able, and it won't break compatibility, we could have a PR to consistently remove the generation from all .ToGatewayUri() overloads |
#6823 changed some behavior slightly. This PR undoes that.