DrChat
commented
1 year ago Want to bump this again. We recently merged some changes to our 1F integration test that makes us dependent on the logs from OneFuzz, and it would be cleaner if we could interpret the logging output from our code directly.
@comcma mentioned that @chkeita said this task might make things easier on your end as well wrt file logging?
Also, maybe there's an opportunity for us to drive this work if we had an outline of what needed to be done?
Cc @jagunter
tl;dr: It'd be useful if we had a separate field in 1F webhooks for raw user task output.
As part of our fuzzer framework, we're signed up for webhooks to get notified when our tasks fail. Usually when our tasks fail, it's because of a panic in our code someplace. However, because the error message reported to webhooks contain 1F logs (which in turn contain logs from our task), it makes it a bit harder to easily scan through and find the fault without understanding what the 1F agent itself outputs.
Most of the time when scanning through error logs, we have to explicitly look for
process (stderr) supervisor:lines in order to find the output we're actually interested in.It would be more useful if we had a separate field that got reported to our webhook that was dedicated to raw output from our task only. Something like
error['output']in the schema.AB#36103