oura icon indicating copy to clipboard operation
oura copied to clipboard

timestamp in preprod with elasticsearch sink wrong

Open pyromaniac3010 opened this issue 2 years ago • 1 comments

Hi, we have a local oura v1.7.1 with elastic sink running on PREPROD using this daemon.toml:

        [source]
        type = "N2N"
        address = ["Tcp", "preprod-relay.<cleared>:6000"]
        magic = "1"
        min_depth = 6
        [source.intersect]
        type = "Origin"
        [[filters]]
        type = "Fingerprint"
        [[filters]]
        type = "Selection"
        [filters.check]
        predicate = "variant_in"
        argument = ["CIP25Asset"]
        [sink]
        type = "Elastic"
        url = "<cleared>"
        index = "preprod.oura.cip25"
        idempotency = true
        [sink.credentials]
        type = "Basic"
        username = "<cleared>"
        password = "<cleared>"
        # Cursor Config only useful when persistent volumes are available
        [cursor]
        type = "File"
        path = "/data/oura-elastic-assets.cursor"
        [metrics]
        address = "0.0.0.0:9186"
        endpoint = "/metrics"

This filters out all NFTs from preprod and stores it into elasticsearch.

The timestamp in Elasticsearch is not correct: https://testnet.cardanoscan.io/transaction/0fabb1543b54f8104fbee6dad0879100776339a0cfe50cfe8d67bb14be0b35bb has it correct with Timestamp 09/20/2022 2:35:34 PM But in Elasticsearch is has: timestamp: 1661949334000 which is 2022-08-31T12:35:34.000Z. This is exactly 20 days wrong.

How does this come? We have a nearly identical setup running on mainnet and legacy testnet and the timestamps are correct over there.

Here the complete elasticsearch document:

{
  "_index": ".ds-preprod.oura.cip25-000001",
  "_type": "_doc",
  "_id": "7994134.cip25.26414156631196745781526705207229726439",
  "_version": 1,
  "_score": null,
  "_source": {
    "@timestamp": 1661949334000,
    "cip25_asset": {
      "asset": "000467",
      "description": "TEST",
      "image": "ipfs://QmXuPwquZJi8oUZ6qDFBtkKBwZFVm9PgXvhuM78jYVmdsZ",
      "media_type": "image/png",
      "name": "000467",
      "policy": "52c4e5bd954271ef717936cbb9a2efa39f6f79a4885d44cb57492d97",
      "raw_json": {
        "description": "TEST",
        "files": [
          {
            "mediaType": "image/png",
            "name": "000467",
            "src": "ipfs://QmNYMreGwSBSFSP8m6YVCdkMVhtrVPNa5Lnmo4doRLKdDd"
          }
        ],
        "image": "ipfs://QmXuPwquZJi8oUZ6qDFBtkKBwZFVm9PgXvhuM78jYVmdsZ",
        "mediaType": "image/png",
        "name": "000467"
      },
      "version": "1.0"
    },
    "context": {
      "block_hash": "0d269d6f79440196208a8b630f199c928328519f385063ef7431dedfac2613c6",
      "block_number": 214232,
      "certificate_idx": null,
      "input_idx": null,
      "output_address": null,
      "output_idx": null,
      "slot": 7994134,
      "timestamp": 1661949334,
      "tx_hash": "0fabb1543b54f8104fbee6dad0879100776339a0cfe50cfe8d67bb14be0b35bb",
      "tx_idx": 0
    },
    "fingerprint": "7994134.cip25.26414156631196745781526705207229726439",
    "variant": "CIP25Asset"
  },
  "fields": {
    "@timestamp": [
      "2022-08-31T12:35:34.000Z"
    ]
  },
  "highlight": {
    "context.tx_hash": [
      "@opensearch-dashboards-highlighted-field@0fabb1543b54f8104fbee6dad0879100776339a0cfe50cfe8d67bb14be0b35bb@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1661949334000
  ]
}

pyromaniac3010 avatar Sep 20 '22 12:09 pyromaniac3010

hi @pyromaniac3010, thanks for reporting. Wall-clock values are not present in block data, so Oura requires a set of well-known values for each network (such as slot length, system start, etc) to compute the timestamps. It is possible that there's a bug in the values that ship for preprod network. We'll double check.

scarmuega avatar Sep 21 '22 09:09 scarmuega

@pyromaniac3010, this has been fixed by #528. It will go out in v1.8.

scarmuega avatar Jan 29 '23 13:01 scarmuega