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

webui: "Invalid Date" shown for both begin and end dates in Ingestion Details panel #353

Open
junhaoliao opened this issue Apr 10, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@junhaoliao
Copy link
Contributor

Bug

Starting with a clean CLP package, after submitting a compression job, occasionally "Invalid Date" is shown for both begin and end dates in Ingestion Details panel, until the next compression statistic update which happens 5 seconds after.
image

CLP version

91b7bd9

Environment

Ubuntu 22.04

Reproduction steps

  1. Build and launch CLP package
  2. Launch WebUI in a browser.
  3. Run ./sbin/compress.sh <logs-path>
  4. Observe "Invalid Date" shown for both begin and end dates in Ingestion Details panel
@junhaoliao junhaoliao added the bug Something isn't working label Apr 10, 2024
@junhaoliao junhaoliao self-assigned this Apr 10, 2024
@junhaoliao
Copy link
Contributor Author

Initial Analysis

  1. By extending STATS_REFRESH_INTERVAL_MILLIS from 5000 to a longer interval, I was able to inspect the compression stats document. It was found that both end_timestamp and begin_timestamp has extremely small/large values:
    image

  2. Looking into the CLP core code, it was found that we define epochtime_t as an int64_t and uses the extreme values of int64_t for cEpochTimeMin=-9223372036854775808 and cEpochTimeMax=9223372036854775807:

    typedef int64_t epochtime_t;
    constexpr epochtime_t cEpochTimeMin = std::numeric_limits<epochtime_t>::min();
    constexpr epochtime_t cEpochTimeMax = std::numeric_limits<epochtime_t>::max();

  3. Those extreme values are not convertible to JS dates.

    A Number can exactly represent all integers from -9,007,199,254,740,992 to 9,007,199,254,740,992 (21.1.2.8 and 21.1.2.6). A time value supports a slightly smaller range of -8,640,000,000,000,000 to 8,640,000,000,000,000 milliseconds. This yields a supported time value range of exactly -100,000,000 days to 100,000,000 days relative to midnight at the beginning of 1 January 1970 UTC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant