Client.userExists method of azwebpubsub unexported

[petrosxen12]

Hello all,

From the documentation of the azwebpubsub package v0.1.0, the types UserExistsOptions and UserExistsResponse are available (reference) , however the method client.UserExists is not available in the documentation.

The method exists in client.go (reference) but appears to be unexported due to lower-case u. This in turn leads to the method not appearing in the package docs.

From client.go line 1188:
func (client *Client) userExists(ctx context.Context, hub string, userID string, options *UserExistsOptions) (UserExistsResponse, error) {

Could we please verify if this is intentional and the Client.userExists method should not be used?

[vicancy]

Thanks for reporting the issue, User/Group/ConnectionExists and CheckPermission APIs are currently not supported by go SDK, it is currently intentionally marked as internal. It is not yet supported because the *Exists REST APIs leverage HTTP response status code 404 to indicate that the User/Group/Connection does not exist. Such logic is not yet supported in go SDK, as explained in this comment https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/messaging/azwebpubsub/autorest.md?plain=1#L34.

Hi @jhendrixMSFT, is there any updates on supporting 404 response code as false method return? Any insights on support such APIs in Go?

[jhendrixMSFT]

The code generator supports this pattern but it's off by default. You'll need to add head-as-boolean: true to the autorest.md file and remove the transform that unexports it before regenerating the SDK.

From our conversations before release, the plan was to omit these APIs until there was an ask for them (the *Exists APIs in general are racy by definition so we omit them by default).

cc @JeffreyRichter

[JeffreyRichter]

Yes, Joel is correct. All *Exists functions encourage customers to write code that is subject to race conditions and so we never recommend the usage of them. In fact, the service probably should not offer these operations. Hence, to lead customers down the pit of success, we purposely hid them from the public interface.

[vicancy]

Hi @petrosxen12, as Jeffrey and Joel mentioned, *Exists functions generally encourages code that can be prone to race conditions and we intentionally hide them for now. That said, we completely understand that different use cases might require different solutions.

Could you share a bit more about your specific scenario where the UserExists API would be helpful? We’d love to better understand your use case and see if there’s a way to address it.