Listen server STDERR and strange outputs

[d00vy]

Been trying to start the listen server and pull the stdout messages, but the only message I get seems to come through stderr even though the bot and the listen server start just fine. It would be nice to be able to get these [INFO] messages from stdout so we can leave stderr for proper error messages. It would also be a nice feature for the listen server to offer more feedback through the shell/stdout (maybe with a --debug flag if necessary), or at least echo the HTTP responses.

Picture for reference: this is the console log when starting the bot with Node's child_process.spawn(), using code identical to the example in the link. The server starts fine, but seems to only respond through stderr

I'm using Windows 10 Pro and my default shell is PowerShell. Sorry, I haven't been able to test if that is relevant.

[svanas]

Ideally, anything that outputs a message starting with [INFO] or [WARN] or [ERROR] should go though log.Print* (eg. outputs to StdErr) and everything else should go through fmt.Print* (eg. outputs to StdOut)

[TaipeiHere]

@doovy based on @svanas ' explanation, did you want to review the repository and make suggestions of which messages you recommend output via StdErr or StdOut or even relabeled as [INFO] or [WARN] or [ERROR]?

[d00vy]

No? As far as I've seen there's only one message that the listen server sends besides actual error messages.

[INFO] The listen server started and everything is great... is a message of success, but it's coming through StdErr. That means we have to determine if the StdErr messages are a good error or a bad error, and that makes error handling really difficult.

[d00vy]

1. DELETE requests always error In the medium.com post it says that when removing a bot you will not receive a response back by design. However, since we're using an HTTP request we still get a response even if it is an error. When sending a DELETE request, the hub deletes the bot fine but it always returns an ERROR status saying Connection was forcibly closed by a peer. I have tried to write conditionals to check for that specific error code so I can catch it, but seems like its a system error and I can't stop it from being thrown. Can we change this to maybe use a HTTP 303 redirect, or send back any other status code that we can try to grab?

2. Deleting a bot by port confuses the hub Lets say we have 3 bots and the hub, so we have ports 38700-38703. If you send a DELETE request to 38702 and then PING the hub, it no longer reports 38703. I assume this is because the port check stops at the first closed port now. Is there a way to make the hub aware of which bots/ports it's currently running or responsible for? Do we have to rely on scanning a port range for responses? We can outsource the responsibility, but it seems silly for the hub to not have some way to keep track of its minions.

3. Bots don't reject random values This is just a weird thing that I found: I can send whatever arguments I want to start a bot and they will always return as part of the bots argument array. For example I can send both price and size to a buy bot, or make up any param that I want and it will report it back. Why does the listen server do this, and is there a way to fix it so that it only reports back args that are applicable?

[svanas]

[INFO] The listen server started and everything is great... is a message of success, but it's coming through StdErr. That means we have to determine if the StdErr messages are a good error or a bad error, and that makes error handling really difficult.

StdErr is for diagnostic output. That is why everything you tell the Go programming language to log, goes to StdErr (including any [INFO] messages). Classic redirection only redirects StdOut but I believe you can pipe StdErr if you want.