Add device id to device_not_found error

[bafonins]

Summary

Currently, NS does not include the device id on device_not_found error. It would be great to have that information included in the error attributes. For example, I get such errors in my gateway data view:

which does not give much information. Would be nice to know which device exactly is not found as I dont see any duplicate errors in the application/device data view.

On the other hand, do we want to expose the device id in the gateway view (hence the discussion label)? Close the issue if not.

Why do we need this?

After #1962 we get more descriptive error events ui:

What is already there? What do you see now?

NS defines the device_not_found error

What is missing? What do you want to see?

device_id attribute similar how AS defines this.

Environment

v3.7.1

How do you propose to implement this?

Adding device id as an attribute to the error definition

Can you do this yourself and submit a Pull Request?

@rvolosatovs

cc @johanstokking

[rvolosatovs]

Please keep in mind that device_id in this case would either be a DevAddr or JoinEUI:DevEUI pair. Perhaps a better approach would be defining different errors per each case.

[johanstokking]

Indeed; I think we should simply start with different errors for the type of search, and include that in the attribute.

I think it's easier if @rvolosatovs picks this up as it's a quickfix, but I'll let you coordinate.

[bafonins]

Please keep in mind that device_id in this case would either be a DevAddr or JoinEUI:DevEUI pair.

I guess DevAddr is fine. We actually show it in the v2 console in the gateway traffic view. I guess anything that can be used to identify a device is better than nothing 🤷‍♂️

Perhaps a better approach would be defining different errors per each case.

Fine as well

[johanstokking]

This could be a good "get acquainted with TTS" issue for @jatinssaluja, a deep dive though, but good to consider

[virtualguy]

Wouldn't you consider this to be an info message rather than an error? This could be indicative of normal traffic for a different network rather than an actual issue. IMHO having this as an ERROR or WARN is just noise and congests the logs and console

[rvolosatovs]

Wouldn't you consider this to be an info message rather than an error? This could be indicative of normal traffic for a different network rather than an actual issue. IMHO having this as an ERROR or WARN is just noise and congests the logs and console

In terms of logging I agree, but we do need to trigger an event when this happens for debugging purposes at least. Event infrastructure does not differentiate between logging levels and console just simply shows the events triggered.

[bafonins]

@virtualguy We are planning to support filtering events in the console (#2231). With this feature in place you will be able to filter out events you are not interested in.