What is the meaning of the value returned by /debug endpoint?

[thevops]

Hi, I didn't find the answer so I'm asking here. What means the below value? Is it a performance metric? For sure, it's a time, but I don't know what that time describes.

❯ curl -s localhost:8080/debug
{
    "elapsed": "0.007215 msec"
}

[cculianu]

Yes it's a performance metric to prepare the response. Mostly the /debug endpoint was for my debugging things in real-time as Fulcrum ran. So it spews forth lots of state information about the various objects and entities the app keeps track of. If you provide no parameters, it just spews forth the amount of time it took to prepare the page.

I didn't document the debug endpoint at all -- but it accepts HTTP GET URL parameters to debug various subsystems. Here is a list of the parameters:

• txnum=<num> - <num> is some integer. Internally Fulcrum numbers txs as they appear on the blockchain in order. This is to debug that system.
• sh=<SCRIPTHASH> - Debug info about a particular "scripthash" (how Fulcrum thinks about addresses on the blockchain)
• unspent=<SCRIPTHASH> - List all the unspent outputs for a particular "scripthash"
• utxo_stats=1 - Show stats on the utxo database and subsystem
• mempool=1 - Show debug info on the current state of the mempool
• subs=1 - Show debug info on the current subscriptions for all connected clients
• dspsubs=1 - Show debug info on the double-spend proof subscription subsystem (BCH only)
• txsubs=1 - Show debug info on the transaction subscription subsystem (Protocol extension, non-standard for Electrum but supported by some BCH clients)

I hope this helps you understand the debug endpoint and how to use it. You can try it by hitting a URL e.g.:

> curl -s 'localhost:8080/debug?utxo_stats=1&subs=1'` # this turns on `utxo_stats` and `subs` stats all in 1 response.

[thevops]

Thanks a lot! Helpful information.

I've tried to do it, but I got some issues:

debuger:~# curl localhost:8080/debug
{
    "elapsed": "0.007380 msec"
}
debuger:~# curl localhost:8080/debug?mempool=1
{
    "error": "Unable to obtain a result within the time period specified"
}
debuger:~# curl localhost:8080/debug
{
    "elapsed": "0.005743 msec"
}
debuger:~# curl localhost:8080/debug?utxo_stats=1
{
    "error": "Unable to obtain a result within the time period specified"
}
debuger:~# curl localhost:8080/debug?subs=1
{
    "error": "Unable to obtain a result within the time period specified"
}
debuger:~# curl localhost:8080/debug?dspsubs=1
{
    "error": "Unable to obtain a result within the time period specified"
}
debuger:~# curl localhost:8080/debug?txsubs=1
{
    "error": "Unable to obtain a result within the time period specified"
}
debuger:~# curl localhost:8080/debug
{
    "error": "Unable to obtain a result within the time period specified"
}

It has not once succeeded. Just simple /debug works, but not every time. It looks like there is too little timeout. Is there any option to increase it?

[cculianu]

Yeah well on a server with clients connected that is busy, it times out and cannot return results. This is because the debug stuff is very low priority task. It really was for debugging when developing .. this is why it is not documented. You can't really use it on a "live" server that has clients or that is synching, etc.

[thevops]

Ok, anyway thanks for your answer.

[cculianu]

Is your node busy synching? If it's synching the debug stuff never works because node is just too busy with higher priority work. If it's just serving requests, some of the /debug?x=y stuff works sometimes if you get lucky.

But while synching.. never. :)

[thevops]

Nope, my node is already synced :) I've configured metrics exporter (https://github.com/EchterAgo/fulcrum-prometheus-exporter), so debug endpoint won't be necessary. Metrics should be enough for checking if it's working.

[cculianu]

Ah.. I see. Yeah debug is useless anyway unless you are ... developing for Fulcrum and want to verify the state it maintains is sane.