Enhancing errors for the metadata api

[Bharadwajshivam28]

Description

I am working on modifying the error handling for metadata API. Currently i have added 2 of them and working on writing more rich error handlers Need some suggestions till here is it going correct?

Issue reference

refs #7489

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Unit tests passing
• End-to-end tests passing
• Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
• Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
• Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

[cicoyle]

looks like you need to run: make lint locally

[Bharadwajshivam28]

Oh... thanks

[cicoyle]

We have a generic not found error in the errors.go file in this same directory you can use instead of creating one specific to the Metadata API

[cicoyle]

Ideally we are passing in more resource info here, otherwise its really not worth adding since you already added the message above

[cicoyle]

typo?

[cicoyle]

actually, why was this added? I don't see this import being used

[Bharadwajshivam28]

typo?

Oh not saw this

[cicoyle]

Did you check where this func is being called? I don't think we should be changing a return of type bool to being an error. I don't know if the caller will expect that and it might cause other issues.

The idea behind the error standardization for the Metadata API was to update err variables that are already in our code base to be our standardized error with more relevant error details.

[Bharadwajshivam28]

Did you check where this func is being called? I don't think we should be changing a return of type bool to being an error. I don't know if the caller will expect that and it might cause other issues.

The idea behind the error standardization for the Metadata API was to update err variables that are already in our code base to be our standardized error with more relevant error details.

Thanks for suggesting I will look in these

[cicoyle]

Thanks for the start on this, however I think there is a long ways to go still. Specifically, there may be some confusion on the Metadata API, and what that is. Here is the Dapr docs for the Metadata API. From there, try to force some Metadata API errors, and update those existing returned errs to be the standardized errors, which are defined from the kit builder.

[Bharadwajshivam28]

Thanks for the start on this, however I think there is a long ways to go still. Specifically, there may be some confusion on the Metadata API, and what that is. Here is the Dapr docs for the Metadata API. From there, try to force some Metadata API errors, and update those existing returned errs to be the standardized errors, which are defined from the kit builder.

I looked into the docs..

I understood that these are the things whichever metadata api will return

It would be great if I get a small example... Although I saw the pr for state and pubsub..

A small example would really help me.. a small and clear one @cicoyle

[Bharadwajshivam28]

Just an example like how one error handler is created for metadata and how it is used @cicoyle

[cicoyle]

There are examples of using the API in the docs link I provided. I sent a very clear example or 2 with links to the line in our codebase in our discord conversation as well. My suggestion is to read the docs link I provided, and try to force an error, then trace that in the codebase.

I would also suggest making this a draft PR, since the tests need to be written as well and polishing up the changes.

[Bharadwajshivam28]

There are examples of using the API in the docs link I provided. I sent a very clear example or 2 with links to the line in our codebase in our discord conversation as well. My suggestion is to read the docs link I provided, and try to force an error, then trace that in the codebase.

I would also suggest making this a draft PR, since the tests need to be written as well and polishing up the changes.

Thanks..
I will implement things by taking help of resources you shared...

Ya let me make it draft pr

[Bharadwajshivam28]

Hello @cicoyle I referred the PR for PubSub API and State API both and the Metadata api docs also api docs

I have a few questions:-

1. I saw in the files of pubsub and state and for pubsub in the line WithErrorInfo(kiterrors.CodePrefixPubSub+PostFixNameEmpty, metadata). we are using CodePrefixPubSub and same in state file we are using WithErrorInfo(kiterrors.CodePrefixStateStore+kiterrors.CodeIllegalKey, nil) we are using CodePrefixStateStore.

My question is that from where we are getting it? When i searched in the Repo I saw we are using it from here kiterrors github.com/dapr/kit/errors so how can i find these for Metadataor can i see how it is created forPubsub or State`

2. In the PubSub and State files we are declaring functions and in Pubsub it takes three parameters func PubSubNameEmpty(name string, pubsubType string, metadata map[string]string) in most of the functions and for state file we pass params but it differs in functionsfunc StateStoreInvalidKeyName(storeName string, key string, msg string).

My question is that is there any good way to find what our function will return?

Thanks.

[Bharadwajshivam28]

I am currently not knowing that what functions will take as Parameters.
Will they take parameters what they will return? Like in Metadata api docs Subscriptions list of pub/sub subscriptions which includes pub/sub name, topic, routes, dead letter topic, and the metadata associated with the subscription.

So do we need to take Parameters based on these?

[cicoyle]

Hello @cicoyle I referred the PR for PubSub API and State API both and the Metadata api docs also api docs

I have a few questions:-

1. I saw in the files of pubsub and state and for pubsub in the line WithErrorInfo(kiterrors.CodePrefixPubSub+PostFixNameEmpty, metadata). we are using CodePrefixPubSub and same in state file we are using WithErrorInfo(kiterrors.CodePrefixStateStore+kiterrors.CodeIllegalKey, nil) we are using CodePrefixStateStore.

My question is that from where we are getting it? When i searched in the Repo I saw we are using it from here kiterrors github.com/dapr/kit/errors so how can i find these for Metadataor can i see how it is created forPubsub or State`

2. In the PubSub and State files we are declaring functions and in Pubsub it takes three parameters func PubSubNameEmpty(name string, pubsubType string, metadata map[string]string) in most of the functions and for state file we pass params but it differs in functionsfunc StateStoreInvalidKeyName(storeName string, key string, msg string).

My question is that is there any good way to find what our function will return?

Thanks.

The CodePrefixPubSub comes from the kit pkg, specifically this file. You posted the import above, the kiterrors.CodePrefixPubSub is referencing the pkg from the import, which you can find on github. Are you familiar with Go and how to use imports? That might be worth looking into if you are not familiar. You should have seen several links to the kit errors pkg, as I know I linked to it from the issue. Did you by chance review all the links provided?

I recommend reading the code there to understand better how to use the pkg when constructing the error with the builder pattern. If you are using an IDE, you should be able to ctrl+click and it should take you to where variables are defined.

The function always returns the error type. If you are asking about the parameters the function accepts, that depends on the API and what makes sense for that specific error you are standardizing.

[dapr-bot]

This pull request has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[dapr-bot]

This pull request has been automatically closed because it has not had activity in the last 67 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!