Need additional logging / error reporting

[lincolnthree]

Hello! Just putting a few thoughts / ideas here.

2020/09/29 17:29:01.457042 [ERR] Subscription simulator.state.680b9abe-4db3-4c4d-9570-e61104ca7847.participants: Reset get error - Internal error: Internal error: invalid value
2020/09/29 17:29:04.498784 [ERR] Subscription simulator.state.680b9abe-4db3-4c4d-9570-e61104ca7847.participants: Reset get error - Internal error: Internal error: invalid value
2020/09/29 17:30:15.548497 [ERR] Subscription simulator.state.680b9abe-4db3-4c4d-9570-e61104ca7847.participants: Reset get error - Internal error: Internal error: invalid value
2020/09/29 17:30:18.646086 [ERR] Subscription simulator.state.680b9abe-4db3-4c4d-9570-e61104ca7847.participants: Reset get error - Internal error: Internal error: invalid value

The above log statements from the Docker container are... helpful, but could use additional clarity to aid in debugging. E.g. What was the actual value that was invalid? It would be helpful to display this information.

Additionally, it would also be helpful if these error were reported back to the NATS resource/micro-service that is attempting to provide the data/responses:

E.g. No errors are thrown from the following NATS client call. The callback function does not seem to have any values.

          client.publish(reply, JSON.stringify({
            result: {
              model
            }
          }));

It does not seem possible to get NATS to provide any kind of error information, via their API, unless I am missing something.

It would be great if there were an error subject to subscribe to accepted/rejected messages from Resgate itself.

Maybe that's available and I've missed it as well?

Cheers!

[jirenius]

@lincolnthree I fully agree with the need to improve the error message on invalid value. I will have a fix done for that for the next release.

I don't think a post-reply feedback message might be the solution. But, as you say, an error subject (configurable per Resgate) where all errors are posted sounds like a good idea. It would allow you to have a single service that can listen to them. And no, it is not available right now. But should be easy to add. :)

The errors comes from the content of model. The model object may only contain primitive values (string, number, boolean, null). In case of arrays and objects as values, you need to "escape" (or wrap) them as data values. A.k.a, put it in an object with a property called "data":

Good (only primitives):

model = {
   str: "Foo",
   num: 42,
   bool: true,
   null: null
};

Bad:

model = {
   obj: { foo: "bar" }, // invalid value
   arr: [ 1, 2, 3 ]     // invalid value
};

Good (objects and arrays are wrapped in data values):

model = {
   obj: { data: { foo: "bar" } }, // valid data value
   arr: { data: [ 1, 2, 3 ] }     // valid data value
};

[jirenius]

Error messages improved in PR #184 The configurable error NATS subject has been added to the backlog.