Fixed the minor nit ;)
> Set to NW as we should either implement the output as well here
The output typing is already implemented here, it is already supposed to be the OutputInterface, just needed to declare the type here:
https://git.drupalcode.org/project/ai/-/merge_requests/1104/diffs#80bc4f...
- mixed $output,
+ protected OutputInterface $output,
And seems no other changes are needed, so move to NR again.
The plan is to implement the feature using this module: https://www.drupal.org/project/external_entities →
Prepared a MR for 2.0.x https://git.drupalcode.org/project/ai/-/merge_requests/1110 - please review.
The logic is the same, but for 2.x additionally we should fix the PHPStan Level 7 issues to, so fixed them in a separate commit to simplify reviewing.
@debdeep.mukhopadhyay, thank you for sharing, but the issue was created for the Navigation component to bring the quick search there. Now I updated the summary to explicitly mention the Navigation module there.
And, by the way, this feature is already implemented in the Admin Toolbar Search submodule!
In the AI Observability module, we already have the ability to log each AI request with metadata to the Drupal Logger and view (when ✨ Add default views to the AI Logging module Active lands). If a context is attached to the request, we can add a new item to the medatata array, something like this:
metadata:
...
used_context_id: [entity_id]
If we add this to the log entry, we will be able to build reports aggregated by this field, that will represent the usage count of each context entity, using the same approach that is used in #3567892: Add aggregated AI Usage reports → .
So, from the technical side, to start logging, we should add the used context reference to the InputInterface and extend the ai_observability events to add the context reference to logs, spans, metrics.
I implemented a basic implementation of the aggregated AI usage report, now with aggregated tables, based on the
Dasboards →
module and Views, it looks like this:
Rendering these reports as charts is also possible with the
Charts →
module, but will come later in a separate issue.
This feature was discussed in Slack as the base feature of the AI module, because for most cases it's crucial to see the token usage details to understand why all the money has disappeared :)
Rebased on the fresh changes, the issue is still wanted to be reviewed ;)
In [#3567673[ I implemented a change for event constructors to accept only InputInterface, so when this will be fixed, we can get rid of the custom code to handle non-typed input, but for now let's keep a workaround in the code, as implemented in the ✨ New submodule to bring logging to OpenTelemetry Active .
I changed the input type in the events to be always InputInterface, and introduced a CustomDataInput for cases when the data doesn't match the existing input types, when the data that come to the ProviderProxy is not typed, it creates a new CustomDataInput project for them. Review please.
That's strange that $event->getInput() return type is mixed, shouldn't it always return the interface Drupal\ai\OperationType\InputInterface?
In the scope of ✨ New submodule to bring logging to OpenTelemetry Active , I added a check for instanceof InputInterface, which should resolve this issue. Let's wait for that issue to be merged, and recheck.
Yeah, the plan is to introduce a separate function stringifyAiPayload() that converts any type of input and output date to the summarized (stringified) representation (plain text probably, or maybe array of strings) to store it in logs, span attributes, etc, with the ability to truncate long data to the max length.
But maybe it's better to move this "stringify" function directly to the InputInterface to implement it on the AI provider side?
Fixed by the fix from 🐛 Product List added as block is not updated by AJAX on filter change Active .
This will be fixed in the scope of 🐛 Cart currency is not changed when changing currency with existing user cart Active
Removed in the scope of 📌 chore: Remove the redundant SettingsController test helper Active .
Fixed in the scope of 🐛 Style up count badges on the Decoupled Filters block Active .
Fixed by using emoji instead of Bootstrap icons.
As a backward compatible option, we can consider switching from the string to a stringable object as a DTO class, so an object that holds the string and all the required metadata, that can be easily converted to a string via something like $value = (string) $response but still can provide the metadata via something like $tokenUsage = $response->getTokenUsage().
We already started to use DTO in AI module (Drupal\ai\Dto) so can just follow the same approach here.
Relying on the last response, I believe, is not a good idea, because we can have multiple parallel requests if we use async Guzzle requests and fibers, so the last response may not be the expected one.
I finally implemented support for OpenTelemetry Spans and Metrics, also added unit tests to cover AI Observability logging and opentelemetry main features.
Now it needs review and local testing.
Released version 1.7.0 that introduces support for Drupal 11.3.x. Unfortunately, some PHP interfaces from Drupal 11.2.x and 11.3.x are incompatible; therefore, 1.7.0 supports only Drupal 11.3.x branch.
Because Drupal 11.2.0 has breaking changes in the interfaces, it seems impossible to make a single version for both versions (11.1 and 11.2), therefore I released the 1.5.2 version that supports Drupal 11.0 - 11.1, then 1.6.0 for Drupal 11.2.
@danrod, thank you for the information, so I'm not alone here, that's good! :)
Okay, since the error comes from core, all that we can do from the module namespace is to add an ignore mark like this:
/**
* {@inheritdoc}
*
* Suppress a PHPStan error:
* ```
* Method Drupal\ai_observability\Form\SettingsForm::validateForm() has
* parameter $form with no value type specified in iterable type array.
* ```
* because it comes from Drupal Core, not from the current code.
*
* @phpstan-ignore missingType.iterableValue
*/
public function validateForm(array &$form, FormStateInterface $form_state): void {
I added a commit with this workaround to make the pipeline green.
@danrod, thank you for the information, so I'm not alone here, that's good! :)
Okay, since the error comes from core, all that we can do from the module namespace is to add an ignore mark like this:
/**
* {@inheritdoc}
*
* Suppress a PHPStan error:
* ```
* Method Drupal\ai_observability\Form\SettingsForm::validateForm() has
* parameter $form with no value type specified in iterable type array.
* ```
* because it comes from Drupal Core, not from the current code.
*
* @phpstan-ignore missingType.iterableValue
*/
public function validateForm(array &$form, FormStateInterface $form_state): void {
I added a commit with this workaround to make the pipeline green.
Maybe we can try another side and somehow ask AI to safely extract and generalize the most interesting parts and approaches of the current site setup, following the security rules, to not extract any security-sentitive information?
Is it mainly a dumping ground for AI to consume Drupal code or for humans to look through ?
If it's a dumping ground for AI, we can name the category as "slop"™ to pay back to AI by a human-generated content 🤣
By the way, Drupal.org can provide a personal repository for Composer packages to motivate people share the code. Because very often developers have some modules that need to be shared between their own multiple websites, but they are not ready to be a full universal project to reuse with the community.
In my projects, I usually create a separate directory modules/shared for modules that are used in multiple projects, or not yet, but intended to be reused later.
For that cases, people usually start their own self-hosted Composer repositories and have to manage them manually. But with Drupal.org, they can just publish those modules to the Drupal.org private space, and configure websites to install modules from it.
By personal repositories I mean not private access, but personal namespaces per Drupal.org account, to not have conflicts with the public modules' names. Something like in NPM - @wondrousllc/fractal-twig-drupal-adapter, etc.
By the way, together with this, Drupal.org can provide paid services for private Composer repos ;)
The idea of sharing such modules is great, but usually they are useless without the full site configuration, because very often developers do not spend time on the installation flow for the new websites, and modules have a lot of dependencies on other modules and manual configuration, which makes them impossible to install and test.
So, it's better to share the full setup with the whole site configuration, not only separate modules without context. But there comes out the security context :)
By the way, how will the issue credits be calculated after moving to GitLab issues - the same way as with Drupal.org issues?
Try to analyze the module https://www.drupal.org/project/external_entities → and reuse its API, or reimplement the same.
Also, for the reference, other related modules:
https://www.drupal.org/project/remote_entity →
https://www.drupal.org/project/views_remote_data →
https://www.drupal.org/project/entity_remote →
Seems it was related to Drupal.org issues, not reproducible now, closing.
Probably, we can combine loading an entity by ID and UUID, and in both functions, fill both static caches (per-id and per-uuid) at once with the same loaded entity object. So, it will be one object storage with two mapping arrays - by ID and by UUID, that will not increase the memory usage significantly.
Seems in the last release everything is fixed in the scope of other issues, closing.
@anoopsingh92, could you please review and merge this fix? It breaks all the Bootstrap dropdowns in the header :(