Alpha: Running List of Bugs Found

[MichaelTaylor3d]

EDIT: Locked this conversation, please move individual items/questions to their own thread. Thank you!

Will keep a running list of bugs found. If something was marked as "patched" you will need to pull the updates and retry the installer to get the update.

The command to get the latest updates:
Navigate to the chia-dig-node repo
run git pull

1. SystemCtl kept crashing

The issue was the result of a null WORKING_DIR in the install.sh file, this has been patched

2. in install.sh, invalid regex expression - this has been patched

3. Cant run install.sh
   To fix make sure to run sudo chmod +x ./install.sh
   This is missing from the documentation. Will post here when its updated.

4. Install file incorrectly says to install docker desktop when it should just be docker for linux: https://wiki.crowncloud.net/?How_to_Install_and_use_Docker_Compose_on_Ubuntu_24_04 this has been patched

[dkackman]

I think I need to do a full reset. I've run the install a couple of times and I think things are mixed up.

When I run dignode remote set peer

I get

Setting peer: 98.61.204.92, Username: xxxxxxxx
Remote set to 98.61.204.92
Failed to login to datastore: You are already logged in to this datastore. Run "dig logout" to login again

dig logout spits out

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> logout
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1205
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;logout.                                IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Sep 26 12:49:20 UTC 2024
;; MSG SIZE  rcvd: 35

but does not correct the issue.

Should i delete everything and start over? Or something else?

[MichaelTaylor3d]

i see this every page or so of stdout

cad4784d18d1_chia-dig-node-propagation-server-1 | Error in sync-stores task: Wallet Not Found

and though the payout task says it has run successfully i don't see any deposit transactions

Your not making payouts right now, so its just a task that does nothing.

[MichaelTaylor3d]

ok. how do i reset the seed phrase. i've logged out and done step 4 again. dignode remote sync seed is not asking for a new seed phrase.

don@durthang:~$ dignode remote sync seed
Syncing remote seed
Using stored credentials for remote 98.61.204.92
Seed phrase successfully set on remote.

well the unofficial way is to delete ~/.dig/keyring.json

or you can try dignode wallet delete default and then dignode wallet new

[thesemaphoreslim]

Glad to hear the new wallet worked. I suspect its either coin fragmentation from older wallets OR hardened vs unhardened wallet addresses that is the real culprit. The act of sending coins to a new wallet resolves the fragmentation and (afaik) all new wallets utilize unhardened addresses.

[MichaelTaylor3d]

Did you create a new wallet specifically for DIG Network or are you reusing an old wallet? I saw reports of old/repurposed wallets not working but freshly created wallets working fine.

I remember @Yakuhito mentioned to me something about the datalayer driver code that something only looks at the first puzzlehash. Maybe if a wallet doesn't have funds there I cant select coins. @Yakuhito does this sound familiar?

[Yakuhito]

Yes, code will only look at the puzzle hash corresponding to the first wallet address - I think you can see it with chia wallet show

[thesemaphoreslim]

I had the same issue with "Failed to login to datastore: You are already logged in to this datastore. Run "dig logout" to login again". I deleted the contents of the ".dig" folder and re-ran the command. That did the trick. Hope this works for you as well.

[MichaelTaylor3d]

while that will work, ideally we can do this with the "logout" cmd.

The CLI needs more work, its hard to keep up with the latest features, but im hoping once we get the rest in a more stable place, we can really focus on a powerful CLI where we wouldnt need to do stuff like that.

[dkackman]

All seems to be working now (except my service configuration but that's ok).

I am seeing payouts coming in... yay!

But when I try to browse the one store im subscribed to it 404's

http://dig.kackman.net:4161/
http://dig.kackman.net:4161/chia.c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352

Am seeing some messages about a null root hash, not sure if related

4ac02f56212e_chia-dig-node-content-server-1      | Extracted values - Chain Name: null Store ID: assets Root Hash: null
4ac02f56212e_chia-dig-node-content-server-1      | Invalid storeId, redirecting to referrer: http://dig.kackman.net:4161/chia.c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352
...
4ac02f56212e_chia-dig-node-content-server-1      | Modified path: /chia.c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352/assets/js/e76e9b48.a33cbb72.js
4ac02f56212e_chia-dig-node-content-server-1      | Extracted values - Chain Name: chia Store ID: c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352 Root Hash: null

[dkackman]

any tips on troubleshooting the default store not being found? not sure where to go from here

[MichaelTaylor3d]

This is not an issue, it's simply a logging observation.

1. The SPA is loaded at <host>/chia.12345.
2. During this load, the SPA retrieves the latest root hash and sets a cookie containing the chain, storeId, and rootHash.
3. After that, the SPA begins loading its dependent resources. However, it incorrectly assumes that it's mounted at <host>/, instead of <host>/chia.12345. For example, it may attempt to load <host>/assets/logo.png, which doesn't include the storeId. In this case, the content server will fallback to using the cookie to determine the storeId. If the cookie is invalid or missing, it will fallback to using the referrer to obtain this information.

As long as the content server is able to successfully serve the requested content in the browser, there's no need to worry about errors.

[dkackman]

As long as the content server is able to successfully serve the requested content in the browser, there's no need to worry about errors.

Sorry wasn't being clear. I'm with you on the log message being a non-issue. However the content is not being served correctly.

http://dig.kackman.net:4161/chia.c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352

shows page not found.

[MichaelTaylor3d]

looks right to me. That "Page Not Found" is a docusaurus issue.

It works find when its mounted to docs.dig.net, but on all the dig nodes it says page not found. This is because of its static routing. Im still trying to find a solution that works on both.

I can flip it and make it work on dig nodes but not docs.dig.net, seems i just cant do both because of the way it does routing.

[dkackman]

ah - gotcha! Thanks Michael

my setup is working then. Will look into the service failure now.

[cartastagnola]

Hi Micheal, thanks for your hard work!
Not sure why, but I had to modify the command docker-compose in docker compose in the systemctl file /etc/systemd/system/dig-node.service to make the service starting.
I am using a clean install of ubuntu server 24.04 and installed docker using apt and the official docker repository.

[MichaelTaylor3d]

I attempted to have it work for both, i will have to take a second try on that

[dkackman]

this change solved my service issues

[thesemaphoreslim]

In an effort to resolve https://github.com/orgs/DIG-Network/discussions/8 I ran "dignode remote store subscribe c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352" and have found that the command hangs permanently at "Remote is subscribing to store". I hafta CTRL+C to escape it.

Update: I guess I finally found a responsive peer because after rebooting my dev machine and re-running the command it finally completed naturally. However, it did not resolve the "Program inactive" error from issue #8 - so still looking for some guidance on that.

[MichaelTaylor3d]

I really would like to know how the CNI UI handles the "No fullnode on local machine" so well. Overall it just seems much more reliable then my implementation. The way i use the network peers its kinda a crap shoot if you find an unresponsive peer. Ive done by best to manage this but it can be dramatically improved.

here is my implementation: https://github.com/DIG-Network/dig-chia-sdk/blob/main/src/blockchain/FullNodePeer.ts

[dkackman]

you mean the CNI UI connecting to a headless node? I wrote that bit of their UI so if that's what you're referring to I can prolly help out.

[MichaelTaylor3d]

they are able to broadcast transactions without a fullnode. But it seems pretty reliable. Im attempting to do the same thing and i wish it was more reliable.

[dkackman]

hmmm... as far as I recall it needs a connection to a daemon running somewhere, local or remote, that is running a full node. and it does all of its communication with that node via the daemon's full_node rpc endpoint over wss. i've never seen the ui operate without access to a dedicated full node/daemon peer but it's been awhile.

[thesemaphoreslim]

My propagation server seems to stop running periodically with the last log message being "Finalizing sync for store c7c0bc885b02531d42c72f11e90be6a22f76ac7d467acbfae76bc02d2221c352...". I've observed this happening twice so far in the past 24 hours. Restarting the service resolves the issue - but it seems to reoccur several hours later. Not sure if this is a node discovery or node communication issue. If I can provide more details just let me know what you need.

[thesemaphoreslim]

I have my Full Node IP specified in the docker-compose.yml but the propagation server never seems to use it. Should it be using my own full node? I suspect what I'm seeing is the propagation server getting hung in the "getBestPeer" function (https://github.com/DIG-Network/dig-chia-sdk/blob/main/src/blockchain/FullNodePeer.ts). One optimization might be to forgo calling "getPeerIPs()" if the user has specified a trusted full node of their own. Only gather peer IPs if the specified trusted full node fails to resolve.

[MichaelTaylor3d]

getBestPeer prioritizes your trusted node, but if it doesnt have the highest peak height it will skip it.

Overall, im not happy with how fullnode connections are handled, ive been through several iterations. Im hoping someone who know more then I do on the subject might be able to improve it.

[ligams]

Gateway timeout on this route sometimes : /chia.<STORE_ID>
This comes from a timeout in node connection :

incentive-server    | NET 104: destroy
incentive-server    | NET 104: close
incentive-server    | NET 104: close handle
incentive-server    | NET 104: pipe false undefined
incentive-server    | NET 104: connect: attempting to connect to 192.168.1.2:8444 (addressType: 4)
incentive-server    | NET 104: emit close
incentive-server    | NET 104: afterConnect
incentive-server    | NET 104: _final: not ended, call shutdown()
incentive-server    | NET 104: _read - n 16384 isConnecting? false hasHandle? true
incentive-server    | NET 104: Socket._handle.readStart
incentive-server    | NET 104: afterShutdown destroyed=false
incentive-server    | NET 104: _onTimeout

[csizo]

Restarting / Updating the Chia node appears to affect DIG services, particularly the payout process.
After restarting DIG services, the payout works again.