Exception handler
The core component of this extension is to modify the default
debug exception handler
from TYPO3 core. For this, the \Elias
class is shipped with the extension.
Configuration
In order to active the modified exception handler, it must be explicitly
configured at $GLOBALS
.
This can be done in the system configuration
file config/
(formerly
public/
):
return [
'SYS' => [
'debugExceptionHandler' => 'EliasHaeussler\\Typo3Solver\\Error\\AiSolverExceptionHandler',
],
];
Once configured, the exception handler tries to provide a solution for the current exception and shows it on the exception page. Depending on the handled exception, there are various types of problem solving.
Attention
For the exception handler to work as expected, make sure you have added an OpenAI API key. This is an essential step, otherwise the exception handler won't be able to provide AI generated solutions and just shows a warning about the missing API key.
Types of problem solving
Streamed solution
New in version 0.2.0
Feature: #64 - Switch to chat completions and implement solution streams
This variant is automatically used if an exception is triggered in a stage
where TYPO3 bootstrapping is already done and therefore a
service container exists. In this
case, the solution is provided asynchronous from an
event stream
by a custom middleware /tx_
.

Solution stream on error page
Note
The extension provides two early-staged middlewares:
- Ensure solution stream is possible by requesting
/tx_
solver/ ping - Provide streamed solution by requesting
/tx_
solver/ solution
Both middlewares are registered to be handled very early, ideally prior to all other middlewares. If you register additional middlewares on your own, make sure they don't conflict with the middlewares provided by this extension.
Read more at Middlewares.
Default solution
There are cases where solution streaming is not possible. For example, if the exception to handle was triggered very early in the bootstrapping process. Those cases prevent solution streaming as it requires a functioning bootstrapping and a successfully built service container.
If solution streaming is not possible, the solution is provided synchronous. This way is less convenient because – depending on the configured attributes – requests to OpenAI may take relatively long, up to several minutes. During the request, no actions can be done as it would interrupt the request and therefore abort problem solving.

Default solution on error page
Note
You can influence long durations a little bit by modifying the attributes used for each request to OpenAI. All supported attributes can be changed in the extension configuration.