- Issue created by @jonas139
- 🇧🇪Belgium jonas139
I added an MR for review. It's a basic concept so feedback is welcome.
- 🇬🇧United Kingdom MrDaleSmith
Not a maintainer and this is just my 2p worth, but this seems like a lot of code to reinvent "log an error message" for a handful of people who need it. The exception throwing has been standardised as the AI module's method of telling the code that something has gone wrong and not to continue processing (which might involve more AI calls and so costs) and I'd be reluctant to introduce something non-standard for one area as that would become expensive to maintain and cause confusion for users.
I'm not sure why standard Drupal logging of the error with more relevant information included won't suit the desired purpose here?
There are multiple test fails in the code so this can't be merged, but I would maybe wait for the maintainers to chip in about the approach before spending any more time working on it?
- 🇧🇪Belgium jonas139
I've used separate entities and a separate overview because for me this shouldn't belong in the general log overview. If you have multiple content managers (who maybe don't have access to the watchdog), they can check this overview and edit the content that belongs to them so, when they save again, the entity is removed from the overview. It's not used as a real 'log' overview in that matter. I do acknowledge the phpstan errors and will look into that if this is still feasible. I just shared this because in my usecase, the client was very happy they had this. But like you said, we'll see what the maintainers have to say.
- 🇬🇧United Kingdom MrDaleSmith
Possibly this would make more sense within the ai_logging sub-module: that already has custom AI-related logs, and moderation failures are something that can happen for any provider type (although I believe Open AI is the only one that moderates by default).