spicypixel•2mo ago

Using v1 Update Organization endpoint in Go SDK and handling errors

I'm trying to use the endpoint as defined here: https://zitadel.com/docs/apis/resources/mgmt/management-service-update-org Relevant handler is: https://github.com/zitadel/zitadel-go/blob/2667335f79f6b437a29b19c0184f6e243beee52e/pkg/client/zitadel/management/management_grpc.pb.go#L1285-L1292 I want to make this call idempotent - that is to say, I want to run this to upsert the name, so if it's the same it stays the same, if it's not, it amends it. Right now it errors if the update of the org name is the same as the current name but I don't want to just catch all the err as an upsert error in case it genuinely didn't work. So my question is: how can I differentiate between a failure and the name being the same as it currently is and the change isn't enacted. Is there an errors.Is() type I can check against to be sure in my client code?

ZITADEL Docs

Change the name of the organization.

GitHub

zitadel-go/pkg/client/zitadel/management/management_grpc.pb.go at 2...

ZITADEL Go - The official client library of ZITADEL for an easy integration into your Go project. - zitadel/zitadel-go

9 Replies

spicypixelOP•2mo ago

I guess a more generic question, how do I deal with any of the GRPC error states from this SDK?

Rajat•2mo ago

hey @spicypixel can you pls share you respomnse did you got?. Curious to see the error code and the response

spicypixelOP•2mo ago

sure, I'll find out it out. fairly sure it's a generic grpc.Status error with code 9 I just haven't used grpc before so haven't a clue how to tell apart the statuses and act on them okay I've not got the time to get the debugger screenshot out today, will respond tomorrow with it That said, it's probably worth documenting/having some error handling in this sdk - just so I can tell what's going on with the calls. I know it's a light auto generated wrapper around the protobuf schemas but it feels like I'm going to need a little more around error handling usecases when using the sdk and various failure states can happen

Rajat•2mo ago

hey @spicypixel thanks for the feedback, I will see what I can do. cc @Mridang Agarwalla

spicypixelOP•2mo ago

(even documenting error handling using the raw underlying existing unwrapped errors would go a long way)

Mridang Agarwalla•2mo ago

Hey Daniel, by any chance do you have a small example of what endpoint you were calling? I could try to reproduce an error and see how we could improve the client-lib. I'm not too familiar with the error handling in this area (yet) so I will spend some time to figure out.

spicypixelOP•2mo ago

Sure I’ll grab it when I get to work

    // TODO: upgrade to v2 endpoint
    //nolint:staticcheck // SA1019
    _, err = s.zitadel.ManagementService().UpdateOrg(withOrgID(ctx, orgId), &mgnt.UpdateOrgRequest{
        Name: params.Name,
    })
    if err != nil {
        s.Logger.Debug().Send()
        // do nothing currently until I can work out how to check for the error state from a GRPC call and check if it's code 9 (name is the same)
    }

    // TODO: upgrade to v2 endpoint
    //nolint:staticcheck // SA1019
    _, err = s.zitadel.ManagementService().UpdateOrg(withOrgID(ctx, orgId), &mgnt.UpdateOrgRequest{
        Name: params.Name,
    })
    if err != nil {
        s.Logger.Debug().Send()
        // do nothing currently until I can work out how to check for the error state from a GRPC call and check if it's code 9 (name is the same)
    }

note: had to throw a noop debug log into the nil check or my ci pipe would fail I'll grab the debugger output for the err value

spicypixelOP•2mo ago

These are the two errors I want to act on, either the org doesn't exist to update (which is a simple one to return on my http api of 404) and name is already set correctly and not changed, in which case I want to continue down the logic and ignore this.

spicypixelOP•2mo ago

Did some googling and this looks useful but having to put inline notes to know what abstract grpc response codes mean in the context of every call to do error handling on isn't the best

    // TODO: upgrade to v2 endpoint
    //nolint:staticcheck // SA1019
    _, err = s.zitadel.ManagementService().UpdateOrg(withOrgID(ctx, orgId), &mgnt.UpdateOrgRequest{
        Name: params.Name,
    })
    if err != nil {
        code := status.Code(err)

        switch code {
        case codes.FailedPrecondition:
            // skip as organization name already matches
            break
        case codes.PermissionDenied:
            return fmt.Errorf("organization missing")
        default:
            return err
        }
    }

    // TODO: upgrade to v2 endpoint
    //nolint:staticcheck // SA1019
    _, err = s.zitadel.ManagementService().UpdateOrg(withOrgID(ctx, orgId), &mgnt.UpdateOrgRequest{
        Name: params.Name,
    })
    if err != nil {
        code := status.Code(err)

        switch code {
        case codes.FailedPrecondition:
            // skip as organization name already matches
            break
        case codes.PermissionDenied:
            return fmt.Errorf("organization missing")
        default:
            return err
        }
    }

especially as they can be changed upstream leaving my error handling block broken, it's effectively going too deep into the grpc private contract in the SDK

Using v1 Update Organization endpoint in Go SDK and handling errors

Did you find this page helpful?