[BUG] Withdrawal attempts through DET keep failing with error

[qwizzie]

OS : Windows 10 Pro
16 GB RAM
DET version (Windows) : v0.1.3
Dash Core wallet version (Windows) : v21.1.1

During withdrawal i get these kind of error messages :

Error: Withdrawal error: Dapi client error: Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Wed, 30 Oct 2024 23:23:43 GMT", "x-envoy-upstream-service-time": "45", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://XXXXXXXX

With only date & "x-envoy-upstream-service-time": xx & uri: changing value with these errors.

And these :

Error: Withdrawal error: Dapi client error: Transport(Status { code: AlreadyExists, message: "state transition already in chain", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 07:02:58 GMT", "x-envoy-upstream-service-time": "10", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri:

Which i can overcome by lowering the withdrawal amount slightly. But then i get the first error.

Error: Withdrawal error: Dapi client error: Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 07:06:49 GMT", "x-envoy-upstream-service-time": "21", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri

In DET, Platform Explorer and mnowatch i see the correct Evonode balance (for DET i needed to reload my Evonodes). Balance does not change after these withdrawal errors and only my previous withdrawal from previous epoch remains visible in Platform Explorer. I have no problem fetching contested usernames, so rpc wise there is communication between Dash Core and DET. I am using owner privatekey to withdrawal, i did change my payout address from Dash Core software wallet address to a hardware wallet address after previous successful withdrawal 9 days ago.

I also tried it in Ubuntu 14.04 LTS (VirtualBox, on my Windows machine), same problem.
I just can't get a withdrawal out and into queue.
I do wonder if this issue is perhaps related to Core v21.1.1 which i am using both in Windows (to get the Platform Transfers visible in my Core wallet) and in Ubuntu 24.04 LTS (Virtualbox).

** see my second post, contains uploaded explorer.log of DET **

[qwizzie]

DET v0.1.3 (Windows) binaries on windows 10 Pro :
Tried it also with Dash Core v21.1.0 : same problem
Tried changing my payout address back to Dash Core wallet address instead of hardware address : same problem
Tried deleting identities.db and loading my Evonodes again : same problem
Even tried switching to older DET v0.1.1 : same problem

DET v0.1.3 (Ubuntu 24.04 LTS / VirtualBox / on my Windows 10 Pro machine) -> dash-evo-tool-x86_64-linux binaries
with Dash Core v21.1.1 : same problem
with Dash Core v21.1.0 : same problem
Tried a new cargo cleaned and cargo build DET, instead of using DET binaries (rm -f /home/qwizzie/dash-evo-tool/identities.db && git checkout -- Cargo.toml && git pull && cargo clean && cargo build && LIBGL_ALWAYS_SOFTWARE=1 cargo run) : same problem with both core v21.1.0 and v21.1.1
Tried with cargo build --release and cargo run --release : same problem

(with same problem i mean constantly hitting code: Internal, message: "Internal error")
Fetching contested usernames no problem, voting on them no problem, trying to initiate a withdrawal --> internal error

dash.conf of Dash Core wallet

rpcport=9998
rpcallowip=127.0.0.1/32
rpcuser=dashrpc
rpcpassword=password
server=1

.env file (in same folder of dash-evo-tool) : same as this one https://github.com/dashpay/dash-evo-tool/blob/master/.env.example

Attached my explorer.log
explorer.log

As a reminder : i previously had a successful withdrawal (9 days ago), now i get these 'internal' errors.

[pshenmic]

#2274 fixes state transition already in chain, should show you a more detailed message about errors in your state transition (i guess in 1.4.2 or 1.5.0, when nodes will deploy that)

[qwizzie]

Hopefully a new DET version (binaries) will fix these ['internal error' issues](code: Internal, message: "Internal error") that are interfering with withdrawals for me right now.

I can work around these 'state transition already in chain' errors by lowering the withdrawal amount, but these ['internal error' issues] are blocking withdrawals for me.

Latest warnings and ending with error from explorer.log when trying to make a withdrawal :

2024-10-31T14:32:03.485865Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:03 GMT", "x-envoy-upstream-service-time": "150", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://157.10.199.77:443/ })
2024-10-31T14:32:04.629118Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:04 GMT", "x-envoy-upstream-service-time": "39", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://157.66.81.130:443/ })
2024-10-31T14:32:04.767330Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:04 GMT", "x-envoy-upstream-service-time": "63", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://185.192.96.70:443/ })
2024-10-31T14:32:58.083024Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:58 GMT", "x-envoy-upstream-service-time": "26", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://2.58.82.231:443/ })
2024-10-31T14:32:58.135681Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:58 GMT", "x-envoy-upstream-service-time": "15", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://185.192.96.70:443/ })
2024-10-31T14:32:58.275153Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:58 GMT", "x-envoy-upstream-service-time": "32", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://159.69.204.162:443/ })
2024-10-31T14:32:58.412421Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:58 GMT", "x-envoy-upstream-service-time": "43", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://185.215.166.126:443/ })
2024-10-31T14:32:58.506784Z WARN request routine: rs_dapi_client::dapi_client: retrying error with sleeping 0 secs error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:58 GMT", "x-envoy-upstream-service-time": "6", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://134.255.182.186:443/ })
2024-10-31T14:32:59.604555Z ERROR rs_dapi_client::dapi_client: request failed error=Transport(Status { code: Internal, message: "Internal error", metadata: MetadataMap { headers: {"grpc-accept-encoding": "identity", "grpc-encoding": "identity", "content-type": "application/grpc+proto", "date": "Thu, 31 Oct 2024 14:32:59 GMT", "x-envoy-upstream-service-time": "10", "server": "envoy"} }, source: None }, Address { ban_count: 0, banned_until: None, uri: https://157.66.81.162:443/ })

[qwizzie]

I managed to get withdrawals out through payout address private key methode. Owner address private key methode is just not working anymore for me. FYI.

[qwizzie]

Another user named CoinRider describing the same issue --> https://www.dash.org/forum/index.php?threads/how-to-withdraw-evonode-rewards-from-dash-platform.55487/#post-240104

Misha too : https://www.dash.org/forum/index.php?threads/how-to-withdraw-evonode-rewards-from-dash-platform.55487/#post-240311

Stealth923 too : https://discord.com/channels/484546513507188745/496953691203698703/1312957450302783651

[pauldelucia]

Withdrawals with owner key still not working as of today as reported by @qwizzie

[pauldelucia]

This seems to be a Platform issue and is planned to be fixed in the next release v1.8