[SERVER-30127] `IDLParserErrorContext` should be available to custom parsers Created: 13/Jul/17  Updated: 27/May/22  Resolved: 27/May/22

Status: Closed
Project: Core Server
Component/s: IDL
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matthew Russotto Assignee: Billy Donahue
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Service Arch 2022-05-30, Service Arch 2022-06-13
Participants:

 Description   

The interface for custom parsing classes right now does not include the parsing context, which means error messages from the custom parser can't include the full context, nor pass it along to further embedded IDL parsers. It would be useful to have the context available.



 Comments   
Comment by Lauren Lewis (Inactive) [ 27/May/22 ]

Ok great, thanks for your confirmation matthew.russotto@mongodb.com. We'll close & revisit if it comes up again.

Comment by Matthew Russotto [ 27/May/22 ]

I don't think this was ever a big deal, so sure.

Comment by Billy Donahue [ 27/May/22 ]

Oh man I still don't get it. Is this something we should just close and worry about if it comes up again?

Comment by Matthew Russotto [ 20/May/22 ]

The idea is when I parsed the decoded resumeToken, instead of passing in IDLParserErrorContext("$resumeToken"), I'd pass either the IDLParserErrorContext I was passed in, or IDLParserErrroContext("$resumeToken", passedInErrorContext). I think one of these would give the result I wanted.

(unfortunately this particular example no longer exists in the code)

Comment by Billy Donahue [ 18/May/22 ]

Ok.
Do you think this could be a matter of just the IDL parser not composing the errors from nested parses properly?
Maybe that is a separately addressable problem.

There's something I still don't understand. Suppose you had access to the IDLParserErrorContext from within the ChangeNotification parser function, how would that have helped achieve the properly embedded and nested message you wanted?

Comment by Matthew Russotto [ 18/May/22 ]

If I properly recall what I was talking about 5 years ago, the issue is we had some BSON structure ChangeNotification

{ field1: [...] field2: [...] resumeToken: <opaque string> }

The resumeToken itself decoded to BSON (using the custom class)

{ fieldA: [...] fieldB:[...] }

We used an IDL parser to parse the resumeToken after decoding. The errors from that parser would always report a problem with "$resumeToken.fieldA" or "$resumeToken.fieldB", when what we really wanted was "$changeNotification.$resumeToken.fieldA" or "$changeNotification.$resumeToken.fieldB".
Or if the $changeNotification was itself nested in some bigger structure, "$someStructure.$changeNotification.$resumeToken.fieldA".

Comment by Billy Donahue [ 18/May/22 ]

Updated title. I assume IDLParserErrorContext was meant there.

I don't understand what IDLParserErrorContext would help with in the example or description.
The "full context" or the "further embedded IDL parsers" are kind of escaping my imagination at the moment.

matthew.russotto@mongodb.com can you clarify how access to the IDLParserErrorContext would help a parser report a better message?

Comment by Lauren Lewis (Inactive) [ 21/Dec/21 ]

We haven’t heard back from you in at least 1 year, so I'm going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Comment by Matthew Russotto [ 13/Jul/17 ]

Yes, this is custom types:

I have an example but it's currently sort of a bad one.

The ResumeToken class in https://mongodbcr.appspot.com/137700001/ is a custom parser called from DocumentSourceChangeNotification. Right now it actually parses by calling back to the IDL again, but we expect to change this in the future to use an opaque string (which may decode to BSON, so we may continue to use IDL, but the custom class will be actually necessary). The top level class uses a context of "$changeNotification", this field should be "resumeAfter", so if the parse fails we'd like a message about $changeNotification.resumeAfter. I think if we had the error context we could do this automatically rather than hardcoding it in the custom class.

Comment by Mark Benvenuto [ 13/Jul/17 ]

Would this be for custom types? Do you have an example in mind?

Generated at Thu Feb 08 04:22:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.