WIP: Resolve "Improve logging and errors returned by GraphQL resolvers" - [closed] #1105

Closed ashleyvega closed 4 years ago

In GitLab by @ashleyvega on Jul 15, 2019, 13:45

Merges 365-improve-graphql-resolvers-logging-errors -> develop

Closes #365

In GitLab by @jeremyletang on Jul 15, 2019, 16:01

because it's not the only error which can come from this function, it's not like you expect only one possible error.

In GitLab by @ashleyvega on Jul 15, 2019, 16:02

policy needed!

In GitLab by @cdm on Jul 15, 2019, 18:32

So, traditionally this string field was just called market (before we had a complex Market proto struct) and therefore all references to that field (string, effectively the market ID) should now be marketID - there was some clean up work a while ago that was supposed to clean this up.

Tangentially I actually quite liked the fields being called 'market' and 'party' because they read well, but that said the more I thought about this it could lead to confusion so the term marketID and partyID are factually correct/descriptively unambiguous

In GitLab by @cdm on Jul 15, 2019, 18:36

"pendingorder" should be pending-order IMO

As IDs are used quite a bit now, it probably makes sense to create OrderID, MarketID, PartyID etc helpers.

In the past I would have either logged the whole Order proto msg or in the case of an orderID just done logging.String("order-id", id) as its lightweight and easy to understand/write - however if we ever changed the type of order-id, then the helper COULD help I guess, or if people typo on the key it could be annoying for a bit until we fix it upstream.

In GitLab by @cdm on Jul 15, 2019, 18:37

I chose to standardise on hyphens, this was my preference and I picked that and went with it (vs dots or underscores). Happy for us to make this a policy/convention.

In GitLab by @cdm on Jul 15, 2019, 18:46

If deserialising the proto etc (as in the above snippet) is genuinely an unexpected Error, I'd log it at Error level internally and provide as much data to help support investigating why e.g. market, order, request, etc to the internal logger. The externally facing message should be sensible and appropriate for the caller.

In GitLab by @ashleyvega on Jul 16, 2019, 09:41

changed this line in version 5 of the diff

In GitLab by @ashleyvega on Jul 16, 2019, 09:41

added 1 commit

869429b8 - Use hyphen in log key

Compare with previous version

In GitLab by @ashleyvega on Jul 16, 2019, 09:41

Done.

In GitLab by @cdm on Jul 18, 2019, 10:36

Is this still WIP, what's the latest - is it ready for final review yet? :)

In GitLab by @ashleyvega on Jul 18, 2019, 10:43

It's still worth a discussion on general logging and error return values.

It would also be able to differentiate between "failed to find X in store Y, but that's fine because the user supplied some junk input" and errors that should never happen, such as "failed to access store Y" or "failed to unmarshal store contents".

<kick obj="can" target="down the road">Or we can ditch this MR and get on with other things.</kick>

In GitLab by @cdm on Jul 18, 2019, 10:49

OK let's roll this chat into the process prep and I'd like to get this merged - but I cant approve it IMO unless you swap the Debugs for Error log levels on line 438 etc

In GitLab by @cdm on Jul 18, 2019, 10:50

https://gitlab.com/vega-protocol/trading-core/issues/373

Created a ticket to capture output and planning

In GitLab by @ashleyvega on Jul 18, 2019, 14:28

closed

vegaprotocol / vega

WIP: Resolve "Improve logging and errors returned by GraphQL resolvers" - [closed] #1105