Refactor and simplify the `_source` parsing in FetchSourceContext by urmichm · Pull Request #21086 · opensearch-project/OpenSearch

urmichm · 2026-04-02T19:51:55Z

Description

Refactoring and simplification of FetchSourceContext.java to better align with current Java best practices.
The first part of resolving the #20612 issue.

To keep this PR focused and easier to understand, the remaining work will be addressed in follow-up PRs.

Related Issues

Partially Resolves #20612

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.

github-actions · 2026-04-02T19:53:04Z

PR Reviewer Guide 🔍

(Review updated until commit `e5ba3ae`)

Here are some key observations to aid the review process:

🧪 No relevant tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ Recommended focus areas for review Missing fall-through In `parseSourceObject`, the switch statement uses arrow-style cases (no fall-through), but the `START_ARRAY` case is missing a `break`/return equivalent concern. More importantly, the `VALUE_BOOLEAN` case in `fromXContent` returns `FETCH_SOURCE` or `DO_NOT_FETCH_SOURCE` directly, but the old code returned `new FetchSourceContext(fetchSource, includes, excludes)` where `includes` and `excludes` defaulted to `Strings.EMPTY_ARRAY`. The new code returns the singleton constants which should be equivalent, but this behavioral change should be validated — especially if callers mutate or compare these objects. case XContentParser.Token.VALUE_BOOLEAN -> { return parser.booleanValue() ? FETCH_SOURCE : DO_NOT_FETCH_SOURCE; } Error Message Change The `ParsingException` constructor calls in the old code passed `parser.getTokenLocation()` as both the location argument and as a trailing argument (likely the `XContentLocation` cause). The new code omits the trailing `parser.getTokenLocation()` argument. This changes the exception details/stack information and may affect error reporting or tests that validate exception messages. throw new ParsingException( parser.getTokenLocation(), "Expected one of [" + XContentParser.Token.VALUE_BOOLEAN + ", " + XContentParser.Token.START_OBJECT + "] but found [" + token + "]" ); } Array parsing behavior change In the old `fromXContent`, when parsing a top-level `START_ARRAY`, the code called `parser.text()` without checking if the token is `VALUE_STRING`, potentially accepting non-string tokens silently. The new `parseSourceArray` method correctly validates token type. However, the top-level `START_ARRAY` case in `fromXContent` (lines 151-158) still uses `parser.text()` without token type validation, unlike `parseSourceArray`. This inconsistency could allow non-string values in top-level arrays. case XContentParser.Token.START_ARRAY -> { ArrayList<String> list = new ArrayList<>(); while ((token = parser.nextToken()) != XContentParser.Token.END_ARRAY) { list.add(parser.text()); } String[] includes = list.toArray(new String[0]); return new FetchSourceContext(true, includes, null); }

github-actions · 2026-04-02T19:53:36Z

PR Code Suggestions ✨

Latest suggestions up to e5ba3ae

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Validate token type in array parsing The `START_ARRAY` case in `fromXContent` calls `parser.text()` on every token without checking if the token is `VALUE_STRING`. Non-string tokens (e.g., nested objects or arrays) would cause unexpected behavior or incorrect values. The existing `parseSourceArray` helper already handles this validation, so it should be reused here for consistency. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [151-158] case XContentParser.Token.START_ARRAY -> { - ArrayList<String> list = new ArrayList<>(); - while ((token = parser.nextToken()) != XContentParser.Token.END_ARRAY) { - list.add(parser.text()); - } - String[] includes = list.toArray(new String[0]); + String[] includes = parseSourceArray(parser).toArray(new String[0]); return new FetchSourceContext(true, includes, null); } Suggestion importance[1-10]: 6 __ Why: The `START_ARRAY` case in `fromXContent` calls `parser.text()` without validating the token type, which could cause issues with non-string tokens. The `parseSourceArray` helper already handles this validation and should be reused for consistency and correctness.	Low
General	Remove unreachable defensive guard check The `parseSourceObject` method is a private helper only called from the `START_OBJECT` switch case in `fromXContent`, so the guard check for `token != START_OBJECT` will never trigger. This is dead code that may mislead future maintainers. Consider removing the redundant check or adding a comment clarifying the precondition. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [182-187] -if (token != XContentParser.Token.START_OBJECT) { - throw new ParsingException( - parser.getTokenLocation(), - "Expected a " + XContentParser.Token.START_OBJECT + " but got a " + token + " in [" + parser.currentName() + "]." - ); -} +private static FetchSourceContext parseSourceObject(XContentParser parser) throws IOException { + // Precondition: parser.currentToken() == START_OBJECT (enforced by caller) + XContentParser.Token token; + String[] includes = Strings.EMPTY_ARRAY; + String[] excludes = Strings.EMPTY_ARRAY; + String currentFieldName = null; + while ((token = parser.nextToken()) != XContentParser.Token.END_OBJECT) { Suggestion importance[1-10]: 4 __ Why: The guard check `token != START_OBJECT` in `parseSourceObject` is indeed dead code since the method is only called from the `START_OBJECT` switch case. However, this is a minor code quality issue and the suggestion to remove it is valid but low impact.	Low

Previous suggestions

Suggestions up to commit 1fa538d

Category	Suggestion	Impact
Possible issue	Validate token type in array parsing The `START_ARRAY` case in `fromXContent` calls `parser.text()` on every token without checking if the token is `VALUE_STRING`. Non-string tokens (e.g., nested objects or numbers) would silently produce incorrect or null values instead of throwing a `ParsingException`. The existing `parseSourceArray` helper already handles this validation correctly and should be reused here. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [151-158] case XContentParser.Token.START_ARRAY -> { - ArrayList<String> list = new ArrayList<>(); - while ((token = parser.nextToken()) != XContentParser.Token.END_ARRAY) { - list.add(parser.text()); - } + List<String> list = parseSourceArray(parser); String[] includes = list.toArray(new String[0]); return new FetchSourceContext(true, includes, null); } Suggestion importance[1-10]: 7 __ Why: The `START_ARRAY` case in `fromXContent` calls `parser.text()` on every token without validating it's a `VALUE_STRING`, which could silently produce incorrect results for non-string tokens. The `parseSourceArray` helper already handles this validation and should be reused for consistency and correctness.	Medium
Possible issue	Guard against null field name before processing If a field value token is encountered before any `FIELD_NAME` token (e.g., malformed input), `currentFieldName` will be `null`, causing a `NullPointerException` when passed to `INCLUDES_FIELD.match(null, ...)`. A null check or an early validation of `currentFieldName` should be added before the switch block. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [188-222] while ((token = parser.nextToken()) != XContentParser.Token.END_OBJECT) { if (token == XContentParser.Token.FIELD_NAME) { currentFieldName = parser.currentName(); - continue; // only field name is required in this iteration + continue; + } + if (currentFieldName == null) { + throw new ParsingException(parser.getTokenLocation(), "Unexpected token " + token + " with no preceding field name."); } // process field value switch (token) { case XContentParser.Token.START_ARRAY -> { ... } case XContentParser.Token.VALUE_STRING -> { ... } default -> { throw new ParsingException(parser.getTokenLocation(), "Unknown key for a " + token + " in [" + currentFieldName + "]."); } } } Suggestion importance[1-10]: 4 __ Why: While a `null` `currentFieldName` scenario is theoretically possible with malformed input, the `existing_code` snippet used in the suggestion doesn't match the actual PR code (it uses `...` placeholders), making it hard to validate precisely. The concern is valid but the risk is low in practice since XContent parsers typically enforce structure.	Low
General	Remove redundant defensive check in private method The guard check at the start of `parseSourceObject` is redundant because `fromXContent` already ensures this method is only called when the token is `START_OBJECT`. While not a bug, if the check is kept for defensive programming, it should remain; however, if removed, the dead code should be cleaned up to avoid confusion. More importantly, the method is `private` and only called from one place, so the check adds no real safety. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [182-187] -if (token != XContentParser.Token.START_OBJECT) { - throw new ParsingException( - parser.getTokenLocation(), - "Expected a " + XContentParser.Token.START_OBJECT + " but got a " + token + " in [" + parser.currentName() + "]." - ); -} +// Guard check removed: caller (fromXContent) guarantees token is START_OBJECT Suggestion importance[1-10]: 2 __ Why: The suggestion to remove a defensive guard check in a private method is a minor style/cleanup concern. The check is harmless and keeping it provides some defensive safety; removing it offers minimal benefit.	Low

Suggestions up to commit 87c4954

Category	Suggestion	Impact
Possible issue	Reuse validated array parsing helper method The array parsing in `fromXContent` does not validate that each token is a `VALUE_STRING` before calling `parser.text()`. Non-string tokens (e.g., nested objects or numbers) would silently produce incorrect results or throw unexpected exceptions. Use `parseSourceArray` (already defined in this PR) to reuse the validated logic. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [151-158] case XContentParser.Token.START_ARRAY -> { - ArrayList<String> list = new ArrayList<>(); - while ((token = parser.nextToken()) != XContentParser.Token.END_ARRAY) { - list.add(parser.text()); - } + List<String> list = parseSourceArray(parser); String[] includes = list.toArray(new String[0]); return new FetchSourceContext(true, includes, null); } Suggestion importance[1-10]: 7 __ Why: The `fromXContent` method's `START_ARRAY` case calls `parser.text()` without validating that each token is a `VALUE_STRING`, while the `parseSourceArray` helper already handles this validation. Reusing `parseSourceArray` here would ensure consistent error handling and avoid potential silent failures with non-string tokens.	Medium
General	Guard against null token in object parser The `parseSourceObject` method re-checks that the current token is `START_OBJECT`, but this check is redundant since `parseSourceObject` is only called from the `START_OBJECT` case in `fromXContent`. However, if `parseSourceObject` is ever called directly with a non-`START_OBJECT` token (e.g., `null` token), `token` could be `null`, causing a `NullPointerException` in the comparison. Add a null check before comparing. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [182-187] -if (token != XContentParser.Token.START_OBJECT) { +if (token == null \|\| token != XContentParser.Token.START_OBJECT) { throw new ParsingException( parser.getTokenLocation(), "Expected a " + XContentParser.Token.START_OBJECT + " but got a " + token + " in [" + parser.currentName() + "]." ); } Suggestion importance[1-10]: 2 __ Why: The null check is largely redundant since `parseSourceObject` is only called from the `START_OBJECT` case in `fromXContent`, making a null `token` practically impossible. The suggestion adds minimal safety value for a private method with controlled call sites.	Low

Suggestions up to commit dbd0800

Category	Suggestion	Impact
General	Remove unused local variable assignment The `parseSourceObject` method checks that the current token is `START_OBJECT`, but `fromXContent` already guarantees this before calling `parseSourceObject`. This guard is redundant but harmless; however, the real issue is that `parseSourceObject` re-reads `parser.currentToken()` at the top, which is fine, but the check duplicates the caller's logic. More importantly, if `parseSourceObject` is ever called from elsewhere without the guard in the caller, it will correctly throw — so the check should remain but the variable `token` assigned at the top of `parseSourceObject` is never used after this check, making the assignment misleading. Consider removing the redundant local variable or using it consistently. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [182-187] -if (token != XContentParser.Token.START_OBJECT) { +if (parser.currentToken() != XContentParser.Token.START_OBJECT) { throw new ParsingException( parser.getTokenLocation(), - "Expected a " + XContentParser.Token.START_OBJECT + " but got a " + token + " in [" + parser.currentName() + "]." + "Expected a " + XContentParser.Token.START_OBJECT + " but got a " + parser.currentToken() + " in [" + parser.currentName() + "]." ); } Suggestion importance[1-10]: 2 __ Why: The suggestion points out that the local `token` variable in `parseSourceObject` is assigned but then used in the guard check, making it not truly unused. The `improved_code` is nearly identical to the `existing_code` (just replacing `token` with `parser.currentToken()` inline), offering only marginal style improvement with minimal impact.	Low

Suggestions up to commit 3e8dee0

Category	Suggestion	Impact
Possible issue	Ensure consistent token type checking The method calls `parser.nextToken()` in the while condition and then immediately calls `parser.currentToken()` inside the loop, which may not be the same token. This can cause incorrect token type checks. Call `parser.nextToken()` first before checking the token type to ensure consistency. server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java [228-241] private static List<String> parseSourceArray(XContentParser parser) throws IOException { List<String> sourceArr = new ArrayList<>(); - while (parser.nextToken() != XContentParser.Token.END_ARRAY) { - if (parser.currentToken() == XContentParser.Token.VALUE_STRING) { + XContentParser.Token token; + while ((token = parser.nextToken()) != XContentParser.Token.END_ARRAY) { + if (token == XContentParser.Token.VALUE_STRING) { sourceArr.add(parser.text()); } else { throw new ParsingException( parser.getTokenLocation(), - "Unknown key for a " + parser.currentToken() + " in [" + parser.currentName() + "]." + "Unknown key for a " + token + " in [" + parser.currentName() + "]." ); } } return sourceArr; } Suggestion importance[1-10]: 8 __ Why: This is a valid and important suggestion. The current code calls `parser.nextToken()` in the while condition but then uses `parser.currentToken()` inside the loop, which could reference different tokens. The improved code correctly captures the token from `parser.nextToken()` into a variable and uses it consistently throughout the loop, ensuring reliable token type checking and preventing potential bugs from token state inconsistency.	Medium

github-actions · 2026-04-02T20:22:06Z

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit 25438a8.

Path	Line	Severity	Description
server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java	136	medium	Logic change in parseFromRestRequest: `fetchSource == null ? true : fetchSource` was replaced with `fetchSource == null \|\| fetchSource`. These are logically equivalent, but the change deserves scrutiny — if `fetchSource` is a Boolean object (not primitive), the new form could behave differently with non-null values depending on unboxing. The intent appears to be a safe refactor, but the semantic difference warrants verification to ensure it cannot be used to force `fetchSource=true` in cases where it should be false.

The table above displays the top 10 most important findings.

Total: 1 | Critical: 0 | High: 0 | Medium: 1 | Low: 0

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

urmichm · 2026-04-02T20:24:39Z

The error message in the default case of fromXContent now includes VALUE_STRING and START_ARRAY as valid tokens, which is an improvement. However, the old error message only listed VALUE_BOOLEAN and START_OBJECT. This is a behavioral change in error messages that could affect users or tests relying on specific error message content.

The error message has been reverted to its original form

Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

extract array parsing as its own function Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

parseSourceObject: split key-value process into different code-blocks Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

Signed-off-by: Andrew Ross <andrross@amazon.com>

github-actions · 2026-04-07T15:25:29Z

Persistent review updated to latest commit 1fa538d

github-actions · 2026-04-07T17:26:36Z

❌ Gradle check result for 1fa538d: null

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?

github-actions · 2026-04-07T19:00:14Z

Persistent review updated to latest commit e5ba3ae

github-actions · 2026-04-07T20:35:05Z

✅ Gradle check result for e5ba3ae: SUCCESS

codecov · 2026-04-07T20:35:53Z

Codecov Report

❌ Patch coverage is 48.57143% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.16%. Comparing base (9bfcc1d) to head (e5ba3ae).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
...arch/search/fetch/subphase/FetchSourceContext.java	48.57%	14 Missing and 4 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21086      +/-   ##
============================================
+ Coverage     73.10%   73.16%   +0.05%     
- Complexity    73213    73259      +46     
============================================
  Files          5968     5968              
  Lines        334539   334530       -9     
  Branches      48174    48170       -4     
============================================
+ Hits         244572   244765     +193     
+ Misses        70421    70178     -243     
- Partials      19546    19587      +41

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

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

bowenlan-amzn · 2026-04-07T21:54:35Z

@urmichm the codecov is not that good, but definitely not because your refactor.
Will let you decide whether some more coverage is good with this PR or easier to do it in your next PR.
I'm good to merge as it is now. cc @sandeshkr419

urmichm · 2026-04-08T06:22:50Z

Hi @bowenlan-amzn
I have unit tests in the next PR, let's keep this one as refactoring only.
The next one will contain all the necessary tests

…ensearch-project#21086) * Init marks for ISSUE-20612 Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * simplification i Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * switch case in favour of if-else-if Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * minor refactor extract array parsing as its own function Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * Refactor parseSourceObject: split key-value process into different code-blocks Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * Refactoring only Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * changelog and spotless Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * error message revert to original Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * parsing array had no validation Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * minor revert, to simplify the PR Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * Rebase and remove changelog entry Signed-off-by: Andrew Ross <andrross@amazon.com> --------- Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> Signed-off-by: Andrew Ross <andrross@amazon.com> Co-authored-by: Andrew Ross <andrross@amazon.com> Co-authored-by: Sandesh Kumar <sandeshkr419@gmail.com> Signed-off-by: Aparajita Pandey <aparajita31pandey@gmail.com>

…ensearch-project#21086) * Init marks for ISSUE-20612 Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * simplification i Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * switch case in favour of if-else-if Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * minor refactor extract array parsing as its own function Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * Refactor parseSourceObject: split key-value process into different code-blocks Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * Refactoring only Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> * changelog and spotless Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * error message revert to original Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * parsing array had no validation Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * minor revert, to simplify the PR Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> * Rebase and remove changelog entry Signed-off-by: Andrew Ross <andrross@amazon.com> --------- Signed-off-by: Mikhail Urmich <m.urmich@jobware.de> Signed-off-by: Mikhail Urmich <urmich.m@gmail.com> Signed-off-by: Andrew Ross <andrross@amazon.com> Co-authored-by: Andrew Ross <andrross@amazon.com> Co-authored-by: Sandesh Kumar <sandeshkr419@gmail.com>

github-actions Bot added enhancement Enhancement or improvement to existing feature or request good first issue Good for newcomers Search:Query Insights labels Apr 2, 2026

urmichm marked this pull request as ready for review April 2, 2026 19:52

urmichm requested review from a team, Bukhtawar, CEHENKLE, Rishikesh1159, anasalkouz, andrross, ashking94, cwperks, dbwiddis, gbbafna, jed326, kotwanikunal, mch2, msfroh, owaiskazi19, reta, sachinpkale, saratvemulapalli, shwetathareja and sohami as code owners April 2, 2026 19:52

urmichm mentioned this pull request Apr 2, 2026

Validation of the _source to reject contradicting and ambiguous requests #20742

Closed

3 tasks

urmichm commented Apr 2, 2026

View reviewed changes

Comment thread server/src/main/java/org/opensearch/search/fetch/subphase/FetchSourceContext.java

urmichm and others added 10 commits April 7, 2026 15:23

simplification i

a563582

Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

switch case in favour of if-else-if

4de63be

Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

minor refactor

0df65ae

extract array parsing as its own function Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

Refactor

5521d68

parseSourceObject: split key-value process into different code-blocks Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

Refactoring only

0c91bd1

Signed-off-by: Mikhail Urmich <m.urmich@jobware.de>

changelog and spotless

0a2b0ab

Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

error message revert to original

1a6b213

Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

parsing array had no validation

8408813

Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

minor revert, to simplify the PR

c629fac

Signed-off-by: Mikhail Urmich <urmich.m@gmail.com>

Rebase and remove changelog entry

1fa538d

Signed-off-by: Andrew Ross <andrross@amazon.com>

andrross force-pushed the 20612-refactoring branch from 856a0a7 to 1fa538d Compare April 7, 2026 15:23

Merge branch 'main' into 20612-refactoring

e5ba3ae

sandeshkr419 merged commit 0dfe59b into opensearch-project:main Apr 8, 2026
14 of 15 checks passed

urmichm mentioned this pull request Apr 8, 2026

[Feature Request] [BUG] _source include / exclude validation #20612

Closed

urmichm deleted the 20612-refactoring branch April 8, 2026 20:05

This was referenced Apr 10, 2026

Validation of the _source object in request and deprecation of ambiguous usage #21203

Merged

Deprecate boolean constructor of FetchSourceContext #21235

Merged

This was referenced Apr 23, 2026

[AUTOCUT] Gradle Check Flaky Test Report for RestoreShallowSnapshotV2IT #16658

Open

[AUTOCUT] Gradle Check Flaky Test Report for ClusterDisruptionIT #14308

Open

[AUTOCUT] Gradle Check Flaky Test Report for RestoreShallowSnapshotV2IT #21374

Closed

Navigation Menu

Uh oh!

Refactor and simplify the `_source` parsing in FetchSourceContext - #21086

Refactor and simplify the `_source` parsing in FetchSourceContext#21086
sandeshkr419 merged 12 commits into
opensearch-project:mainfrom
urmichm:20612-refactoring

urmichm commented Apr 2, 2026

Uh oh!

github-actions Bot commented Apr 2, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Apr 2, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Apr 2, 2026

Uh oh!

Uh oh!

urmichm commented Apr 2, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

codecov Bot commented Apr 7, 2026 •

edited

Loading

Uh oh!

bowenlan-amzn commented Apr 7, 2026

Uh oh!

urmichm commented Apr 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

urmichm commented Apr 2, 2026

Description

Related Issues

Check List

Uh oh!

github-actions Bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit e5ba3ae)

Uh oh!

github-actions Bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Code Suggestions ✨

Previous suggestions

Uh oh!

github-actions Bot commented Apr 2, 2026

PR Code Analyzer ❗

Uh oh!

Uh oh!

urmichm commented Apr 2, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

github-actions Bot commented Apr 7, 2026

Uh oh!

codecov Bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

bowenlan-amzn commented Apr 7, 2026

Uh oh!

urmichm commented Apr 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions Bot commented Apr 2, 2026 •

edited

Loading

(Review updated until commit `e5ba3ae`)

github-actions Bot commented Apr 2, 2026 •

edited

Loading

codecov Bot commented Apr 7, 2026 •

edited

Loading