btw, is it possible to increase the verbosity of the client code somehow? Doesn't have to be a CLI flag or anything if that's complicated, a code change is fine, but would be useful to be able to see a little more of the client decisions...

We don't really have much logging. But what are you looking for?

We don't really have much logging. But what are you looking for?

was just interested to see what sort of decisions the client is making in general -- e.g. was interested in test_snapshot_rollback[basic] but since the refresh succeeds, there's nothing in the output (like which metadata versions it successfully loads)

but if there's no logging like that then I know I'll have have to add some if I really want to know.

there is some issue with the stream redirection:

• it all works great the first time tuf-cli-server sends a request and processes a response...
• further tuf-cli-server invocations will not get the expected output in the json response (whether in the same test or another test)
• exception stack trace still ends up in the jsonResponse somehow

What I imagine might happen (caveat: I barely read java):

• I have added logging call in Updater.java: this works once after tuf-cli-server-all.jar server is started (the log line goes all the way to tuf-conformance output). After that it never works again
• the Updater logger is a class variable so is created when the class is first instantiated: at this point the stream is the correct stream for this test invocation
• when a new Updater is instantiated, the logger stderr uses the old stream and not the stream that would end up in the new jsonResponse

This might not be important enough to fix considering what Appu said -- there's not much logging in the code.

yeah I think we could run the server in a mode which tees the output to stdout/err as well as returning it to the conformance suite. So if someone happened to be testing locally running the server in a different terminal than the tests, then we'd be okay.