Closed kdenhartog closed 3 years ago
What is the use case for this? I'm guessing it's something like displaying the error in a UI like the json-ld.org playground. The term is added to the error details so it is possible to access with err.details.term
. I hesitate to have this one place where we construct the error message with specific details. Here and elsewhere we've been using the details object to hold extra info depending as appropriate. Those details are something that should be exposed in the playground if that was the issue here.
The intent is to be able to show which protected term is causing issues in tests being run in CI pipelines like the security v3 context. Typically the full objects aren't returned by jest, but it will return the full error message meaning that if the term is included it can be seen easily within the tests run.
Ideally, we should do this type of change for the variety of different errors that get thrown during context processing, but this was the only one I was focused on when trying to figure out the issues with usage of protected in security v3.
Merging. Thanks again, @kdenhartog!
I've been fighting this error blindly for too long. It's time we shed some light on which terms are causing conflicts when protected.