Great work @julie_huang! I've tested this locally and changes LGTM 👍

One question for this work in general (not specific to the changes in this MR): existing self-hosted models that haven't been updated will retain the API provider since the before_save hook won't have fired to infer the correct value. Are there implications now that provider field is being exposed via GQL and eventually consumed in the FE? Is there a plan to backfill these records so we don't need to rely on user intervention to infer the correct provider value?

@erran I agree with Duo– guardrailConfig should only be included for Bedrock providers, otherwise it'll break other provider models (see: !4715 (comment 3172995187))

Thanks for working on this @erran! I managed to get Bedrock Guardrails setup conveniently in my individual AWS account thanks to the skills you've added

Observations:

✅ For Bedrock models (either provided through GitLab-managed or self-hosted), Guardrail config is passed to LiteLLM. It appears twice (as highlighted here) but this is an issue with LiteLLM.

‼️ When testing out Guardrails (in this case by including fake AWS keys in the prompt), an A1002 error is returned to Duo Chat UI, instead of the Guardrail intervened message in Draft: fix: Treat guardrail_intervened as an ab... (!4934). In the logs, the error message is: Your request was blocked by a guardrail policy. Please revise your input and try again.

‼️ The guardrails config is also passed for non-Bedrock models (ex: Vertex, Fireworks), which results in an A1004 error:

note: FYI, guardrailConfig appears twice at the top-level and nested within inferenceConfig. I believe this is an issue with LiteLLM, there's a fix MR open to resolve this.

praise: thank you for adding these as skills. super neat and makes setup a lot easier! 🤩

note: in my case it's 'ServiceSpecificCredential.ServiceCredentialSecret'– ServiceApiKeyValue does not exist.

For context, @aying-gl and I are referring to this GDK script. Would it make sense to create a similar customer-facing version they can run on their instance to diagnose configuration issues and share logs with support teams?

Thanks @lulalala, LGTM!

What does this MR do and why?

Update agentic chat feature to use duo_chat UT

Remove feature flag check to determine duo_chat/duo_classic_chat because those UT's scope should be enough to determine accessibility.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. ensure both chat works as expected
2. disable classic chat in a group's feature setting and see it disappear from the UI.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #581229

Thanks @lulalala! I've reviewed the changes and verified them locally against the following self-hosted cases:

Case	Result
Offline license with DAP self-hosted add-on Online license with any add-on	✅ can access Duo Chat ✅ can access agentic chat ✅ model used are correctly based on selected model for feature setting
Offline license with Duo Enterprise add-on	✅ can access Duo Chat ✅ cannot access agentic chat

I left one comment regarding specs.

Confirmed that there are no usages of allowed_to_use?(:chat, unit_primitive_name: :duo_chat) outside of this diff 👍

This is expected– mapping different features based on ai_feature was introduced because we couldn't distinguish between DAP and agentic chat feature setting by unit primitives. This change makes this possible as :duo_classic_chat UP is now reserved for classic chat and :duo_chat for agentic chat.

question: i would think the access_duo_classic_chat specs are still relevant. Thoughts on only removing the no_duo_classic_for_duo_core_users disabled flag conditions?