It seems to me like a legacy issue appeared again on this last release @Kammerlo. Happened on preprod.
Issue is theres nothing wrong with the query nor with the chain so replying 200 http code for internal errors breaks the wallet in our case. I have the feeling that there is a lag between the indexer and background service while trying to process assets. Tested on several of our nodes, all of them are failing the same way for some minutes.
Steps to reproduce the bug
How to replicate:
mint assets on a new cardano address
run this query during indexing process
minutes later query will work as expected
Other way of testing is using the in-wallet airdrop feature (this is how we discovered it)
Query:
fragment _UTXOs on Query {
utxos(
#distinct_on:$distinct_on
#limit:$limit
#order_by:$order_by
#offset:$offset
where:$where
){
txHash
address
index
#transaction
tokens{
quantity
asset{
assetId
assetName
fingerprint
policyId
# name
}
}
value
}
}
fragment _GetProtocolParams on Query {
epochs(
limit:1
order_by:{number:desc}
){
number
protocolParams{
coinsPerUtxoByte
}
}
genesis{
alonzo{
maxValueSize
lovelacePerUTxOWord
executionPrices{
prSteps {numerator denominator}
prMem {numerator denominator}
}
maxTxExUnits{
exUnitsMem
exUnitsSteps
}
maxBlockExUnits{
exUnitsMem
exUnitsSteps
}
collateralPercentage
maxCollateralInputs
}
shelley{
protocolParams{
poolDeposit
keyDeposit
minUTxOValue
minFeeA
minFeeB
maxTxSize
}
}
}
}
fragment _GetTip on Query {
cardano {
tip {
number
slotNo
slotInEpoch
epochNo
forgedAt
}
}
}
query PaymentAddresses($where: TransactionOutput_bool_exp){
..._GetTip
..._GetProtocolParams
..._UTXOs
}
Summary
It seems to me like a legacy issue appeared again on this last release @Kammerlo. Happened on preprod.
Issue is theres nothing wrong with the query nor with the chain so replying 200 http code for internal errors breaks the wallet in our case. I have the feeling that there is a lag between the indexer and background service while trying to process assets. Tested on several of our nodes, all of them are failing the same way for some minutes.
Steps to reproduce the bug
How to replicate:
minutes later query will work as expected
Other way of testing is using the in-wallet airdrop feature (this is how we discovered it)
Query:
variables:
Actual Result
200 http response breaking our client side code (probably Graphql Apollo don't like this response):
Expected Result
http 200
Environment
CARDANO_GRAPHQL_VERSION=8.3.0
Platform
Platform version
Ubuntu server 20.24
Runtime
Runtime version
No response