Fix a regression issue of parsing datetime string with custom time format in Span

[LantaoJin]

Description

This seems a regression issue from https://github.com/opensearch-project/sql/pull/2762. Query of StatsBy with Span on a custom formatted date type will fail.

Here is the reproduce:

PUT /ltjin-test1
{
    "mappings":{
        "properties": {
            "Time1": {
                "type": "date",
                "format": "yyyy-MM-dd"
            },
            "Time2": {
                "type": "date",
                "format": "epoch_millis"
            }
        }
    }
}

POST _bulk
{ "index" : { "_index" : "ltjin-test1", "_id" : "1" } }
{ "Time1": "2005-12-05", "Time2": 1133654400000 }

POST /_plugins/_ppl/
{
    "query": """
    source=ltjin-test1 | eval a = 1 | stats Count(a) as a by span(Time1, 1d)
    """
}

POST /_plugins/_ppl/
{
    "query": """
    source=ltjin-test1 | eval a = 1 | stats Count(a) as a by span(Time2, 1d)
    """
}

Throws NPE.

Related Issues

Resolves #3078

Check List

• [x] New functionality includes testing.
• [ ] New functionality has been documented.
  • [ ] New functionality has javadoc added.
  • [ ] New functionality has a user manual doc added.
• [ ] API changes companion pull request created.
• [x] 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.

[LantaoJin]

Please increase unit test coverage and resolve now failing integration tests.

The unit test coverage can't be fixed since jacoco report is module-level based. What's the bug here is missing the OpenSearchDateType handling in Rounding logic , but OpenSearchDateType is not a class in the core module. And the current fixing is straightforward. I fixed the previous failures in DateTimeFormatsIT and add a new test case to DateTimeImplementationIT.

[LantaoJin]

@YANG-DB @MaxKsyunz @penghuo , since this seems a regression issue introduced from v2.16.0. I'd like this fixing could be merged in v2.18.0

[penghuo]

could u exclude Rounding from TestCoverage and address it later. otherwise, following PR will failed with test coverage?

[LantaoJin]

could u exclude Rounding from TestCoverage and address it later. otherwise, following PR will failed with test coverage?

Excluding Rounding is not what we expected, there are many logic in class Rounding, IMO jacoco only fail the incremental codes which is less than the threshold of coverage, the following PR shouldn't be impacted.

Does anyone else could help to confirm?^ cc @dai-chen @ykmr1224

[LantaoJin]

I added some unit tests in a mock way to fix the missing test coverage. Now CI passed! Please take a review again @YANG-DB @MaxKsyunz @penghuo @dai-chen @ykmr1224. This patch could be marked as critical for 2.18.0!

[opensearch-trigger-bot[bot]]

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/sql/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/sql/backport-2.x
# Create a new branch
git switch --create backport/backport-3079-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 4ff1fe3cb48a17ff17b0cf134131283fc0282205
# Push it to GitHub
git push --set-upstream origin backport/backport-3079-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/sql/backport-2.x

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

[opensearch-trigger-bot[bot]]

The backport to 2.18 failed:

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

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/sql/backport-2.18 2.18
# Navigate to the new working tree
pushd ../.worktrees/sql/backport-2.18
# Create a new branch
git switch --create backport/backport-3079-to-2.18
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 4ff1fe3cb48a17ff17b0cf134131283fc0282205
# Push it to GitHub
git push --set-upstream origin backport/backport-3079-to-2.18
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/sql/backport-2.18

Then, create a pull request where the base branch is 2.18 and the compare/head branch is backport/backport-3079-to-2.18.