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

Do not throw exception when flat_object field is explicitly null #15375

Merged

Conversation

msfroh
Copy link
Collaborator

@msfroh msfroh commented Aug 23, 2024

Description

It is valid for a flat_object field to have an explicit value of null. (It's functionally the same as not specifying the field at all.) Prior to this fix, though, we would erroneously advance the context parser to the next token, violating the contract with DocumentParser (which says that a call to parseCreateField with a null value should complete with the parser still pointing at the null value -- it is DocumentParser's responsibility to advance).

Related Issues

N/A

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

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.

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>
Copy link
Contributor

❌ Gradle check result for b416205: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Signed-off-by: Michael Froh <[email protected]>
Copy link
Contributor

✅ Gradle check result for 0a952c3: SUCCESS

Copy link

codecov bot commented Aug 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.87%. Comparing base (9014894) to head (0539f08).
Report is 3 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main   #15375      +/-   ##
============================================
- Coverage     71.96%   71.87%   -0.09%     
+ Complexity    63319    63203     -116     
============================================
  Files          5224     5224              
  Lines        296138   296137       -1     
  Branches      42777    42777              
============================================
- Hits         213110   212863     -247     
- Misses        65546    65733     +187     
- Partials      17482    17541      +59     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@reta
Copy link
Collaborator

reta commented Aug 26, 2024

Could you please add changelog entry? seems like a bugfix

@reta reta added v2.17.0 v3.0.0 Issues and PRs related to version 3.0.0 labels Aug 26, 2024
@msfroh
Copy link
Collaborator Author

msfroh commented Aug 26, 2024

Could you please add changelog entry? seems like a bugfix

Sure!

Signed-off-by: Michael Froh <[email protected]>
@msfroh msfroh added backport 2.x Backport to 2.x branch and removed skip-changelog labels Aug 26, 2024
Copy link
Contributor

✅ Gradle check result for 3d6e908: SUCCESS

Copy link
Contributor

❕ Gradle check result for 0539f08: UNSTABLE

  • TEST FAILURES:
      1 org.opensearch.http.SearchRestCancellationIT.testAutomaticCancellationDuringFetchPhase

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

@msfroh msfroh merged commit 46a269e into opensearch-project:main Aug 26, 2024
33 of 34 checks passed
@msfroh msfroh deleted the do_not_throw_on_null_flat_object branch August 26, 2024 21:11
@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-15375-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 46a269ef21e88e3cb1398474e4bf82af4c3b3b7f
# Push it to GitHub
git push --set-upstream origin backport/backport-15375-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-15375-to-2.x.

msfroh added a commit that referenced this pull request Aug 26, 2024
)

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>

* Fix unit test

Signed-off-by: Michael Froh <[email protected]>

* Add changelog entry

Signed-off-by: Michael Froh <[email protected]>

---------

Signed-off-by: Michael Froh <[email protected]>
(cherry picked from commit 46a269e)
reta pushed a commit that referenced this pull request Aug 27, 2024
) (#15431)

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>

* Fix unit test

Signed-off-by: Michael Froh <[email protected]>

* Add changelog entry

Signed-off-by: Michael Froh <[email protected]>

---------

Signed-off-by: Michael Froh <[email protected]>
(cherry picked from commit 46a269e)
akolarkunnu pushed a commit to akolarkunnu/OpenSearch that referenced this pull request Sep 10, 2024
…nsearch-project#15375)

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>

* Fix unit test

Signed-off-by: Michael Froh <[email protected]>

* Add changelog entry

Signed-off-by: Michael Froh <[email protected]>

---------

Signed-off-by: Michael Froh <[email protected]>
dk2k pushed a commit to dk2k/OpenSearch that referenced this pull request Oct 16, 2024
…nsearch-project#15375)

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>

* Fix unit test

Signed-off-by: Michael Froh <[email protected]>

* Add changelog entry

Signed-off-by: Michael Froh <[email protected]>

---------

Signed-off-by: Michael Froh <[email protected]>
dk2k pushed a commit to dk2k/OpenSearch that referenced this pull request Oct 17, 2024
…nsearch-project#15375)

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>

* Fix unit test

Signed-off-by: Michael Froh <[email protected]>

* Add changelog entry

Signed-off-by: Michael Froh <[email protected]>

---------

Signed-off-by: Michael Froh <[email protected]>
dk2k pushed a commit to dk2k/OpenSearch that referenced this pull request Oct 21, 2024
…nsearch-project#15375)

It is valid for a flat_object field to have an explicit value of
null. (It's functionally the same as not specifying the field at
all.) Prior to this fix, though, we would erroneously advance the
context parser to the next token, violating the contract with
DocumentParser (which says that a call to parseCreateField with
a null value should complete with the parser still pointing at
the null value -- it is DocumentParser's responsibility to advance).

Signed-off-by: Michael Froh <[email protected]>

* Fix unit test

Signed-off-by: Michael Froh <[email protected]>

* Add changelog entry

Signed-off-by: Michael Froh <[email protected]>

---------

Signed-off-by: Michael Froh <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.x Backport to 2.x branch backport-failed v2.17.0 v3.0.0 Issues and PRs related to version 3.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants