🇪🇸Spain @gxleano

The response also appears immediately in https://www.drupal.org/project/ai/issues/3526074 🐛 Deepchat response not displayed until page reload when stream option is enabled Active , the problem is that the FE doesn't show the answer until the page is reloaded

I think that both issues are reporting the same problem https://www.drupal.org/project/ai/issues/3526074 🐛 Deepchat response not displayed until page reload when stream option is enabled Active , adding it as related.

I believe Drupal's navigation is a special case and shouldn't be handled the same way as other components. Its structure is unique, and supporting the before/after/no text options could introduce inconsistencies.

Looking at the UI Icons Menu logic, I noticed that the icon is currently wrapped inside <span class="toolbar-button__label">, which doesn't align well with the new navigation requirements. For it to work correctly, the icon should be placed outside this <span>. The previous implementation introduced by @plopesc seems more appropriate here, as this behavior is specific to the Navigation component.

Thanks @mogtofu33 for the feedback.

I've been testing the latest changes but it is breaking down the logic, we come back to the current "buggy" state.

It will be included in release 1.2.40

Thanks @robbiehobby to report the issue!

I have been checking your changes and everything seems to be working fine, but now we are getting an error in the browser console when the updated field is in use.

See:

Thanks Simon!

It will be included in release 1.2.40

gxleano → made their first commit to this issue’s fork.

Would it be needed in 1.1.x?

gxleano → changed the visibility of the branch 3521601-server-context to hidden.

Test are failing, so we should check this before to move to RTBC.

Moving changes from 1.0.x to 1.1.x in order to move forward this topic.

gxleano → made their first commit to this issue’s fork.

gxleano → made their first commit to this issue’s fork.

Someone is trying to embed some piece of content and it fails the Embeddings call due to moderation api. Right now in OpenAI module this is hardcoded to do moderation checkups if you have moderation enabled. When this fails, that tag is to be forwarded into the moderation call so this can be logged somehow for editors to check where its failing to embed.

Could we consider that this is going to be handled by https://www.drupal.org/project/ai/issues/3526710 🐛 [Error] The Prompt is unsafe: The prompt was flagged by the moderation model, stop the indexation Active ?

gxleano → changed the visibility of the branch 3525311-1.0.x-fix-gitlab-ffi to active.

gxleano → changed the visibility of the branch 3525311-1.0.x-fix-gitlab-ffi to hidden.

gxleano → created an issue.

gxleano → created an issue.

After applying the changes everything works as expected.

At the end of the indexation we will get an error message pointing to the logs, where we could check which content has been flagged by moderation.

See evidences:

Closing this issue, for now we are going to use the LoggerChannelTrait in the extended class.

This issue needs to come together with #3526710: [Error] The Prompt is unsafe: The prompt was flagged by the moderation model, it stop the Search API indexation

gxleano → created an issue.

gxleano → created an issue.

Here we have an example of wrong output:

gxleano → created an issue.

You are using 1.1.x for all the AI modules above and set it up freshly, correct?

Yes, all the modules in the AI stack are coming from 1.1.x

I will try to spend some time today in order to debug it and can add more information about the issue itself.

In order to have more context about the issue, this is the stack that I am using to reproduce it:
- Drupal 11.1.7 with Umami

Modules installed:
- ai
- ai_api_explorer
- ai_assistant_api
- ai_chatbot
- ai_search
- key
- search_api
- ai_agents
- ai_provider_openai
- ai_vdb_provider_milvus
- ai_agents

Hey @anjaliprasannan

Thanks for your feedback. Unfortunately, it didn’t work on my end. Honestly, I don't think this should be handled through the prompt, this seems like a feature that should work out of the box as part of the tool.

Testing in a clean installation with Drupal 10.4.7 and 1.1.x AI stack and everything works fine.

Seems like some module from the other installation is interfering on this.

Closing the issue.

Testing in a clean installation with Drupal 10.4.7 and 1.1.x AI stack and everything works fine.

Seems like some module from the other installation is interfering on this.

Closing the issue.

I am testing the patch in AI 1.1 and it is working as expected.

Using the next embedding strategy:

• Max chunk size: 500 tokens
• Minimum chunk overlap: 100 tokens
• Contextual content percentage: 25%

It has reduce a lot the indexation time.

What else would we need to move it to RTBC?

gxleano → created an issue.

gxleano → created an issue.

Testing 1.1.x and this issue will be handled there with tooling approach, so I will close it.

Thanks Marcus!

I can reproduce this issue in 1.1.0-beta1. It appears that when the allow_history option is set to either session or session_on_thread, the Rag Tool in this case—is not being properly initialized.

As a result, we're seeing responses similar to those described in this issue.

Everything works fine if we are not allowing history.

gxleano → created an issue.

Tested with latest version of Core and UI Icons, and everything works as expected.

See evidences:

It will be included in release 1.2.39

Thanks Dieter to report it and work on it.

It will be part of release 1.2.39

Thanks Dieter!
It works as expected and will be part of release 1.2.39

gxleano → made their first commit to this issue’s fork.

@pbonnefoi, thanks for reporting the issue.

I'd say that this problem has been solved on https://www.drupal.org/project/tagify/issues/3505861 🐛 Custom ajax event not working on select widget Active , could you try to update to the latest version (1.2.38) and let me know if everything work fine in your end, please?

Thank you very much for the suggestion, @ok4p1. In this case, it doesn't apply to the selection widget but rather to the Tagify widget when the onClick option is enabled in Tagify widget (autocomplete). At the moment, I don’t see a clear use case for this behavior, so we’ll proceed to close the issue as "won’t fix" for now. Nevertheless, we truly appreciate your input, so please don’t hesitate to share any further ideas or feedback!

Postponed until this part https://drupal.slack.com/archives/C072JMEPUS1/p1744975851620219?thread_t... is clear.

gxleano → created an issue.

Tagify Select widget will be handled into a separate issue.

See: https://drupal.slack.com/archives/C072JMEPUS1/p1744975851620219?thread_t...