Logging exceptions thown during AJAX requests if in development mode...?

[smuuf]

I have noticed this behavior quite some time ago, but now I finally had time to investigate it a bit.

Example scenario

• I'm developing an app which relies heavily on cooperation between PHP (server side) and some JS UI components (client side).
• JS component makes a request to the server.
• PHP backend begins to handle that request.
• "Oh noes! There is some kind of error within the PHP code - an exception is thrown."
• JS component sees a HTTP 500 error and displays a nice error message, cool.
• I, as the developer, want to investigate what went wrong, I would like to see the exception/error file (bluescreen dumped to HTML file), that surely must have been stored...
• I go into the Nette's log folder and see it empty: "Oh... 🤔 The exception was not persisted to the log folder by the debugger."

Why? After spending some time step-debugging, I discovered this piece of code in Tracy's Debugger.php:

tracy/src/Tracy/Debugger/Debugger.php

Lines 321 to 324 in af8c8cd

	} elseif ($firstTime && Helpers::isHtmlMode() || Helpers::isAjax()) {
	self::getBlueScreen()->render($exception);
	} else {

(I am using Tracy v2.6.8, but here a very similar condition is seen in the master branch, so I guess the behavior is still the same...?)

Is there any specific reason why these ajax exception are not stored as files, as would "ordinary" (non-ajax) exceptions be?

Because, the way I see it, logging AJAX-request-errors is maybe even more essential than ordinary non-ajax exceptions (which I can simply see in the browser). So I guess I'm just asking - is this on purpose...? 🤔

• If yes, what's the reasoning behind it? I can't think of any, but maybe I'm unaware of some nuanced logic.
• If not, maybe this issue really is a feature request! 🙂 (which naively seems to be achievable by just adding a single line self::log($exception, self::EXCEPTION); in there...)

[smuuf]

Relates to https://forum.nette.org/cs/17844-tracy-reagujici-na-ajax-pozadavky#p146840

[...] Napr mam form ktery zpracovavam ajaxove a v onSuccess eventu si schvalne vyhodim vyjimku, ve firelogu vydim ze to padlo ale v adresari logs nic neni (pokud zpracuju bez ajaxu, objevi se ladenka a exception je ulozena do logs)… v predchozi verzi (2.0.15) to myslim fungovalo, ma s tim nekdo zkusenost?

[dg]

Helpers::isAjax() returns true on AJAX request that is handled by Tracy JavaScript (bar.js). In case of error 500, it should download in another request the BlueScreen (stored in session) and display it. Therefore, it is not logged.

I have no idea where the error arises in this process.

[smuuf]

FWIW I'm still encountering this - with a little twist.

This time I'm developing app which exposes HTTP API which enables some third-party program to report some stuff back to my app (imagine a separate program on another machine and it calls my app's /report API endpoint over the internet).

I have a program that simulates this third-party program and makes HTTP requests to my local API written in Nette (in development mode) - and those requests result in errors (obviously because of some faulty logic in my work-in-progress app). The problem is, again, those errors are not logged by Tracy in my app and I have no idea what these errors might be.

Tracy does generate a bluescreen and sends it back as a response to the third-party program's HTTP request, but this program simply discards it (it really doesn't care what my app returns back).

So, in this scenario (which is not hypothetical) there's not even a "Tracy JavaScript (bar.js)" present.

There is no browser to display the error. The response is tossed away - and I simply need my Tracy to log these currently invisible errors 🍀.

---

Also, I lied a bit, I could simulate the error by doing the request manually:

curl -X POST http://127.0.0.1:8080/report --data '{"blablah"}' 2>/dev/null

... and the bluescreen would be right there in my terminal:

But that's not very readable, so to actually see the bluescreen I would need to do:

curl -X POST http://127.0.0.1:8080/report --data '{"blablah"}' > maybe_some_exception.html

... and then open this new file manually in browser. (Which is not very developer-friendly and I would need to do this repeatedly to kill all bugs and to assess how my API endpoint behaves for various HTTP payloads.)

Or... 🤔 Tracy could simply allow logging errors that occur when in development mode.

---

This change in tracy/tracy/src/Tracy/Debugger/Debugger.php actually seems to be enough:

... and the idea of just making a PR crossed my mind, but I'm a bit worried about larger implications of doing this always and by default. Not everyone might need this all the time, so I'm thinking more in terms of new configuration options for Tracy - but I don't think I have enough knowledge about its codebase to do it.

So I'm here just thinking out loud - this feature would be nice.

[dg]

Switching Tracy into production mode should solve that.

(Now I realized that the AJAX requests, that the initial issue is about, weren't sent with the X-Requested-With header, right?)

[smuuf]

Oh, looks like that's on me. It was quite late friday evening when I posted the last comment.

The original post does really concern AJAX requests (with the X-Requested-With header). The last post does not concern AJAX requests (I apologize for not making this clear), but rather is about general inability of Tracy to log errors while also being in development mode (if I am not mistaken).

But the solution I'm aiming for (having an option to be in development mode and at the same time have the ability to tell Tracy I want to log exceptions in HTML files) should be able to solve both of these problems.

Switching Tracy into production mode should solve that.

... this is what I'm doing right now as a workaround, but it is a rather inconvenient way of development, where I have to turn the production mode off, and on, and off again, on again... - depending on whether I'm debugging an error shown inside browser or trying to make a HTTP request to my endpoint via curl running inside terminal next to my browser window.

[matronator]

Bumping this as I also just got f*cked by Tracy not logging Ajax requests.

[dg]

I am unable to reproduce this error, it works good for me. So please send me the minimal code (repository) where the error occurs. Or a patch.

Otherwise, we're not moving forward, and I will close this issue as time goes on.

[smuuf]

Yeah, let's close it.