[cestercian]

Fixes #254

str(NextcloudException) only gives the status and reason, so when e.g. scheduling the LLM task fails with a 412 the log never shows what the server actually said.

This adds format_exception() to ex_app/lib/logger.py. It returns the usual traceback and then walks the cause/context chain, appending OCS response for [status]: <body> for every NextcloudException that carries a response (capped at 2000 chars). The walk matters because nc_model.py re-raises some of these as Exception(...) from e. AsyncNextcloudApp gives you niquests AsyncResponses, where .text is a coroutine, so the helper is async and awaits it (it also handles the sync Response str). If reading the body fails, it just falls back to the plain traceback.

The error logs in main.py (fetching the next task, streaming, task failure, reporting) now use it. Those go to stdout and to the Nextcloud log through log().

There is no test suite in the repo, so I checked it locally against nc-py-api 0.30.3 with a small script covering sync and async responses, a wrapped exception, a response whose body cannot be read, and a non-Nextcloud exception. I ran it with -W error so an un-awaited coroutine would fail it.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[WSHAPER]

Nice change thanks for the contribution! Approving with a few non-blocking nits:

• Optional: the seen/current chain walk could become a small _exception_chain generator to flatten the loop in format_exception.
• Optional: a logger.debug(..., exc_info=True) before return None in the except Exception branch, so failures reading the body aren't completely silent.
• Naive Question: can OCS error bodies contain anything sensitive (tokens, user content)? They're now logged at WARNING, so it's worth a quick check?
• Nit: format_exception is easy to confuse with traceback.format_exception at call sites. format_exception_with_ocs_body might read clearer.

[cestercian]

thanks! renamed it to format_exception_with_ocs_body and added the debug log before the return None. left the generator refactor out to keep the diff small.

on the sensitive data question: the body is capped at 2000 chars, and the standard OCS error shape is just meta status/statuscode/message plus data. message is the controller status text (stuff like "Not found" or "Password confirmation is required"), so tokens aren't part of it. some endpoints can put resource names or validation details in message/data though, so happy to drop it to DEBUG if you'd rather not have that at WARNING.

[marcelklehr]

Thanks, could you rebase onto latest main branch, pls?

[cestercian]

Rebased onto latest main. Kept the new poller and handle_task split, and the new log sites use the OCS body helper too. Should be good for another look.

[cestercian]

rebased onto main. the new log sites from main (fetch errors, unhandled task errors etc) use format_exception_with_ocs_body too, except _restart_bg_task since that callback is sync and can't await it.