Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: better exception message #969

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

brianf-aws
Copy link
Contributor

Description

Fixes two logging issues

  1. (for logging Id instead of docid) Suppose a user has a target field that has "3.3" the expected behavior is to throw an exception saying that [3.3] is not numerical This makes it very difficult to understand why It didn't rerank. In this commit it provides the class of the mapping used to rerank to let the user now why it went wrong.
  2. (for explicitly calling out the type) The previous logging used docId to be able to tell the user where in the search hit the error occured. The problem is that docId is not guaranteed in every document however _id is.Instead this commit makes sure that it uses getId() instead of docID(). Previously if you had indexed your document and then used docId it would return -1 when it had no direct document field.

Testing

  1. ./gradlew spotlessApply
  2. ./gradlew integTest
  3. ./gradlew test to check UT

Why this occurred?

  • (for logging Id instead of docid) Various types of testing was provided however for each sample data I was forced to provide a documentId on creating a searchHit thus a logical docId was chosen.
  • (for explicitly calling out the type) previously my only edge case would be if they provided a non numerical string. It ddint occur to me that someone may want to provide something like "3.3" to add on when it outputs it will say [3.3] is not a number instead where it could have been ["3.3"] is not a number.

Related Issues

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff.
  • Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Previously used docId for saying where the problem is, there is no gauarantee that this field exists instead _id is always guaranteed to be there. Also logging of the mapping was provided because it may be misleading when a user has a number as a string. It can be confusing for a user to something like [3.3] is not a number when the reality is that it was sent like "3.3" thus the type of the value is provided to help users understand better

Signed-off-by: Brian Flores <[email protected]>
@yuye-aws
Copy link
Member

yuye-aws commented Nov 4, 2024

2. (for explicitly calling out the type) The previous logging used docId to be able to tell the user where in the search hit the error occured. The problem is that docId is not guaranteed in every document however _id is.Instead this commit makes sure that it uses getId() instead of docID(). Previously if you had indexed your document and then used docId it would return -1 when it had no direct document field.

Thanks for creating this PR. Can you provide a few examples so that I can better understand the nuance between getId() and docID()?

@@ -985,7 +985,10 @@ public void testRerank_throwsExceptionOnHavingNonNumericValue_WhenTargetFieldHas
ArgumentCaptor<Exception> argumentCaptor = ArgumentCaptor.forClass(Exception.class);
verify(listener, times(1)).onFailure(argumentCaptor.capture());

assertEquals("The field mapping to rerank by [hello world] is not Numerical", argumentCaptor.getValue().getMessage());
assertEquals(
"The field mapping to rerank by [hello world] is not Numerical, instead of type [java.lang.String]",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you turn it into a string format, where [java.lang.String] gets in the same way as typeOfMapping?

}

Optional<Object> val = getValueFromSource(sourceMap, targetField);

if (!(val.get() instanceof Number)) {
log.error(String.format(Locale.ROOT, "The field mapping to rerank [%s: %s] is not Numerical", targetField, val.orElse(null)));
// Strictly get the type of value removing the prefix of getClass() having a value is guaranteed so no NPE check
String typeOfMapping = val.get().getClass().toString().replace("class ", "");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that val.get().getClass().toString() also have strings like class ? I would suggest replaceFirst.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getClass().getSimpleName() should be enough to avoid the replace and give you just the class name

@martin-gaievski
Copy link
Member

can you please check that this will work when the _source is disabled, just want to make sure docId is not affected but that setting

@martin-gaievski
Copy link
Member

@brianf-aws is this still work in progress?

@brianf-aws
Copy link
Contributor Author

Hey @martin-gaievski I paused on this mainly because we mentioned this was not urgent. I am not sure what time I should prioritize this, what are your thoughts?

@martin-gaievski
Copy link
Member

I don't think it's high priority, how about we close the PR for now, and then reopen once you have bandwidth for it? Let me know if you have objects/concerns

@brianf-aws
Copy link
Contributor Author

Sounds good, thanks for understanding

@brianf-aws brianf-aws closed this Nov 22, 2024
@brianf-aws
Copy link
Contributor Author

Hey everyone I want to reopen this PR and work on it, I should have more bandwidth with the holidays coming up.

@brianf-aws brianf-aws reopened this Dec 13, 2024
@brianf-aws brianf-aws requested a review from minalsha as a code owner December 13, 2024 18:01
@martin-gaievski
Copy link
Member

Good to see this reopened @brianf-aws, please let us know once it's ready for review

@yuye-aws
Copy link
Member

@brianf-aws Is there any update? We can help you if you came across some challenges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants