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

Caused by: com.fasterxml.jackson.databind.JsonMappingException: Numeric value (685052082000000000) out of range of int (-2147483648 - 2147483647) #100

Closed
DevStakePool opened this issue Dec 3, 2022 · 8 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@DevStakePool
Copy link

The latest version shows this stack trace

2022-12-03 20:12:51.376 ERROR 629917 --- [WalletActivityChecker1] c.d.t.scheduler.TransactionCheckerTask   : Caught throwable while checking wallet transaction

rest.koios.client.backend.api.base.exception.ApiException: Numeric value (685052082000000000) out of range of int (-2147483648 - 2147483647)
 at [Source: (okhttp3.ResponseBody$BomAwareReader); line: 1, column: 416] (through reference chain: java.util.ArrayList[0]->rest.koios.client.backend.api.transactions.model.TxInfo["invalid_after"])
        at rest.koios.client.backend.api.transactions.impl.TransactionsServiceImpl.getTransactionInformation(TransactionsServiceImpl.java:60) ~[koios-java-client-1.16.0.jar!/:na]
        at com.devpool.thothBot.scheduler.TransactionCheckerTask.checkTransactionsForUsers(TransactionCheckerTask.java:205) ~[classes!/:1.1.0]
        at com.devpool.thothBot.scheduler.TransactionCheckerTask.run(TransactionCheckerTask.java:140) ~[classes!/:1.1.0]
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[na:na]
        at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[na:na]
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[na:na]
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[na:na]
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[na:na]
        at java.base/java.lang.Thread.run(Thread.java:829) ~[na:na]
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Numeric value (685052082000000000) out of range of int (-2147483648 - 2147483647)
 at [Source: (okhttp3.ResponseBody$BomAwareReader); line: 1, column: 416] (through reference chain: java.util.ArrayList[0]->rest.koios.client.backend.api.transactions.model.TxInfo["invalid_after"])
        at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:392) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:351) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.wrapAndThrow(BeanDeserializerBase.java:1821) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:315) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:176) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer._deserializeFromArray(CollectionDeserializer.java:355) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:244) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:28) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:2051) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1459) ~[jackson-databind-2.13.3.jar!/:2.13.3]
        at retrofit2.converter.jackson.JacksonResponseBodyConverter.convert(JacksonResponseBodyConverter.java:33) ~[converter-jackson-2.9.0.jar!/:na]
        at retrofit2.converter.jackson.JacksonResponseBodyConverter.convert(JacksonResponseBodyConverter.java:23) ~[converter-jackson-2.9.0.jar!/:na]
        at retrofit2.OkHttpCall.parseResponse(OkHttpCall.java:243) ~[retrofit-2.9.0.jar!/:na]
        at retrofit2.OkHttpCall.execute(OkHttpCall.java:204) ~[retrofit-2.9.0.jar!/:na]
        at rest.koios.client.backend.api.base.BaseService.execute(BaseService.java:141) ~[koios-java-client-1.16.0.jar!/:na]
        at rest.koios.client.backend.api.transactions.impl.TransactionsServiceImpl.getTransactionInformation(TransactionsServiceImpl.java:57) ~[koios-java-client-1.16.0.jar!/:na]

This happens when calling this method:
rest.koios.client.backend.api.transactions.TransactionsService#getTransactionInformation(java.util.List<java.lang.String>, rest.koios.client.backend.factory.options.Options) with a list of TXs

@rdlrt
Copy link

rdlrt commented Dec 3, 2022

Could you also list the transactions? That TTL seems too high, a bit surprised that cardano-node does not have upper bound for transactions if so>

Nvm - checked max TTL currently on mainnet is 18446744073634242062, example below:

{
    "tx_hash": "5738f941a3a422345d210b76056695dad68d5dd2653fb226fd8e2d36b64d1618",
    "block_hash": "9eb3ac8bc44171964edfc13fb623abce05900ae22698be8bcd580d29f24754de",
    "block_height": 5509898,
    "epoch_no": 255,
    "epoch_slot": 387884,
    "absolute_slot": 25184684,
    "tx_timestamp": 1616750975,
    "tx_block_index": 5,
    "tx_size": 297,
    "total_output": "300116941249",
    "fee": "174081",
    "deposit": "0",
    "invalid_before": null,
    "invalid_after": 18446744073634243000,
    "collateral_inputs": [],
    "collateral_output": null,
    "reference_inputs": [],
    "inputs": [
      {
        "value": "300117115330",
        "tx_hash": "55908485f00d7156fcd1f7e77e49b28405d6083be345f9be43c5b1755b0f5d6f",
        "tx_index": 1,
        "asset_list": [],
        "datum_hash": null,
        "stake_addr": "stake1u8wzan33n9dzw69340x0fnsf082nf0maz9p3l2j8nwtk6qqc2frd6",
        "inline_datum": null,
        "payment_addr": {
          "cred": "b36badaeb3ac8022d051f5e55dce4e9f8da1647e3d4d29d6ab360bd2",
          "bech32": "addr1qxekhtdwkwkgqgks28672hwwf60cmgty0c7562wk4vmqh5ku9m8rrx26ya5tr27v7n8qj7w4xjlh6y2rr74y0xuhd5qqc8fhry"
        },
        "reference_script": null
      }
    ],
    "outputs": [
      {
        "value": "80065620",
        "tx_hash": "5738f941a3a422345d210b76056695dad68d5dd2653fb226fd8e2d36b64d1618",
        "tx_index": 0,
        "asset_list": [],
        "datum_hash": null,
        "stake_addr": "stake1u8kph2mc9r6j2plndz5j27quu06faverhra5lmprax99xqq9cvu9k",
        "inline_datum": null,
        "payment_addr": {
          "cred": "c74140d3c5946dc5fdb4cf97f0c9fed6f138969005d81d3ba12b714c",
          "bech32": "addr1q8r5zsxnck2xm30akn8e0uxflmt0zwykjqzas8fm5y4hzn8vrw4hs284y5rlx69fy4upecl5n6ej8w8mflkz86v22vqqvf746p"
        },
        "reference_script": null
      },
      {
        "value": "300036875629",
        "tx_hash": "5738f941a3a422345d210b76056695dad68d5dd2653fb226fd8e2d36b64d1618",
        "tx_index": 1,
        "asset_list": [],
        "datum_hash": null,
        "stake_addr": "stake1u8wzan33n9dzw69340x0fnsf082nf0maz9p3l2j8nwtk6qqc2frd6",
        "inline_datum": null,
        "payment_addr": {
          "cred": "b36badaeb3ac8022d051f5e55dce4e9f8da1647e3d4d29d6ab360bd2",
          "bech32": "addr1qxekhtdwkwkgqgks28672hwwf60cmgty0c7562wk4vmqh5ku9m8rrx26ya5tr27v7n8qj7w4xjlh6y2rr74y0xuhd5qqc8fhry"
        },
        "reference_script": null
      }
    ],
    "withdrawals": [],
    "assets_minted": [],
    "metadata": null,
    "certificates": [],
    "native_scripts": [],
    "plutus_contracts": []
  }

@DevStakePool
Copy link
Author

Hi, I managed to find the TX:

curl -X POST "https://api.koios.rest/api/v0/tx_info" \
 -H "Accept: application/json" \
 -H "Content-Type: application/json" \
 -d '{"_tx_hashes":["5c54bad11d5c1b9d80c20dd671920e8a76dc7af9c0fef4637c2b91601b8bdd95"]}' \

@edridudi edridudi self-assigned this Dec 4, 2022
@edridudi edridudi added the bug Something isn't working label Dec 4, 2022
@edridudi edridudi added this to the 1.16.1 milestone Dec 4, 2022
@edridudi
Copy link
Collaborator

edridudi commented Dec 4, 2022

@rdlrt , looks like schema for invalid_before/invalid_after should be changed to String or Long/Number

@rdlrt
Copy link

rdlrt commented Dec 5, 2022

The actual data type used in database is wordtype64 which essentially ranges up to 18446744073709551615. Now, the open API spec would only recognise integer/numeric types (both types not enforcing an upper bound), so would you rather this to be changed into str instead similar to lovelaces? If so, this might need to be done across all the endpoints when talking about slot numbers, which might not be 'fun' for Library builders (was hoping to keep next release with 0 breaking changes, but if it needs to be done, it can be)

@DevStakePool
Copy link
Author

My 2ct, I'm fine with having it changed into string if you can't use native large java numbers like BigInteger

@edridudi
Copy link
Collaborator

edridudi commented Dec 5, 2022

@rdlrt I can change it to String just as of currently.
This is to be applied only for this library although I prefer it to be aligned with the open API schema.

I need your confirmation that it will be String in the future.

@DevStakePool I think serializing these fields to BigInteger will affect performance in speed and memory and I want to keep it lightweight as much as possible.

@rdlrt
Copy link

rdlrt commented Dec 5, 2022

This is to be applied only for this library although i prefer it to be aligned with the open api schema.

So far - looks all that have seen/discussed it are happy with str for this field itself in next release, but the bigger discussion point is then considering all other wordtype64 fields that currently show up as integer or numeric , as in theory - they should accordingly change to string too. Thus, the likeliness for this field to be str is pretty high 👍🏻

rdlrt added a commit to cardano-community/koios-artifacts that referenced this issue Dec 6, 2022
…nfo to show latest mint tx data (#141)

## Description
<!--- Describe your changes -->
1. [Minor output (data-type) change] - Convert tx_info: TTL values to string (as some values are far beyond billion) - assists cardano-community/koios-java-client#100
2. [Non-breaking] - Fix asset_info/asset_policy_info to show latest mint tx data (was an error in change before intended to do the same), and update asset_info->tx_hash to show latest (instead of oldest) tx
edridudi added a commit that referenced this issue Dec 10, 2022
@edridudi
Copy link
Collaborator

Thanks @DevStakePool, @rdlrt
Issue Fixed in Version 1.16.1.

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

3 participants