[Automated] Draft docs (agentgateway): config store: reject writes validated against a stale snapshot (+4 related)

assets/agw-docs/standalone/setup/ui/launch.md

@@ -115,6 +115,10 @@ Whether the UI can save the changes that you make depends on your storage mode.
 {{< version exclude-if="1.0.x,1.1.x,1.2.x,1.3.x,1.4.x,1.5.x,1.6.x,2.2.x" >}}
 The UI checks a change before it writes the configuration file. If the change is not valid, the save fails with an error and the file does not change.
 
+The UI preserves comments and formatting when the YAML structure can be updated in place. If the YAML structure cannot be updated safely, the UI rewrites the validated configuration file instead of failing the save.
+
+With database storage, the UI validates concurrent saves against the latest stored configuration before it writes them. One save cannot overwrite another save while validation is running.
+
 If you edit the file outside the UI and agentgateway rejects the reload, the UI shows a **Configuration reload failed** banner. Agentgateway keeps running the previous valid configuration. The UI and `/api/config/effective` show the file on disk, including the rejected change. To retry the reload, fix the file and save it again.
 {{< /version >}}
 

assets/agw-docs/standalone/virtual-keys.md

@@ -57,7 +57,7 @@ flowchart TD
 > [!NOTE]
 > You can manage virtual keys two ways: interactively in the built-in [UI]({{< link-hextra path="/documentation/setup/ui/" >}}), or declaratively in your config file. The UI is convenient for exploring and one-off changes. The config file is the source of truth for GitOps workflows.
 
-## Set up virtual keys (UI)
+## Set up virtual keys (UI) {#set-up-virtual-keys-ui}
 
 Set up virtual keys interactively through the UI.
 
@@ -72,6 +72,10 @@ Set up virtual keys interactively through the UI.
    {{< reuse-image-dark srcDark="img/ui-virtual-keys-new-dark.png" alt="Create virtual key drawer with name, auto-generated key value, and metadata" >}}
 3. **Copy** the virtual key value. Give this key to your users to use in an `Authorization: Bearer $VIRTUAL_KEY` header in subsequent requests through agentgateway.
 
+{{< version exclude-if="1.5.x,1.6.x" >}}
+To rotate a key that was generated by the UI, edit the key and click **Regenerate**. The UI creates a new `agw_sk_...` value. After you save, copy the replacement value and distribute it to users that should keep access.
+{{< /version >}}
+
 The rest of this guide uses the equivalent config-file settings, which apply the same `apiKey` policy shown in the UI.
 {{< /version >}}
 

content/docs/standalone/main/documentation/observability/access-logs/view.md

@@ -72,14 +72,14 @@ Only the built-in HTTP field set is renamed. The `gen_ai.*` and `mcp.*` fields a
 > [!NOTE]
 > The preset changes only the stdout access log, and only for HTTP traffic. A TCP listener has no HTTP field set to rename, so the preset has no effect there. An OTLP export already uses semantic convention attribute names, so it is unaffected. For more information, see [Export logs over OTLP]({{< link-hextra path="/documentation/observability/access-logs/export/" >}}).
 
-## View access logs in the UI
+## View access logs in the UI {#view-access-logs-in-the-ui}
 
 The agentgateway UI includes a **Logs** page that you can use to review the access logs that were captured by your proxy. 
 
 To view access logs in the UI: 
 
 1. Open the [agentgateway UI](http://localhost:15000/ui). This address is the copy of the UI on the admin interface, which works from the host that runs the proxy. If you serve the UI on a gateway, use that gateway's port instead. 
-2. Go to **Logs** and review the access logs that agentgateway captured for your previous requests. Use the filter options to limit the number of access logs that are shown to you. For example, you can filter logs by model, providers, or users. Note that in order to filter logs by user, you must configure authentication in agentgateway. 
+2. Go to **Logs** and review the access logs that agentgateway captured for your previous requests. Use the filter options to limit the number of access logs that are shown to you. For example, you can filter logs by model, providers, or users. The **Users** and **Groups** filters include search boxes that narrow values already discovered from stored traffic. Select a value to change the log query. To filter logs by user, configure authentication in agentgateway.
 
    {{< reuse-image src="img/agentgateway-ui-logs.png" srcDark="img/agentgateway-ui-logs-dark.png" >}}
 

content/docs/standalone/main/release-notes/release-notes.md

@@ -15,8 +15,10 @@ Review the release notes for agentgateway standalone.
 ### Traffic management and operations {#v17-operations}
 
 <!-- ref: https://github.com/agentgateway/agentgateway/pull/3842 -->
+<!-- ref: https://github.com/agentgateway/agentgateway/pull/3656 -->
 
 - **Standalone Helm session key Secret**: Set `session.secretName` to load the AES-256-GCM session key from an existing Kubernetes Secret. The chart passes the Secret's `key` entry to the proxy as the `SESSION_KEY` environment variable, which takes precedence over `config.session.key`. For more information, see [Use an existing session key Secret]({{< link-hextra path="/documentation/setup/install/helm/#helm-session-secret" >}}).
+- **Agentgateway UI management workflows are safer to use**: The UI can search Users and Groups values in Logs and Analytics filters, regenerate generated virtual API keys while editing, and protect database-backed configuration saves from concurrent writes. When a YAML edit cannot preserve formatting, the UI rewrites the validated configuration instead of failing the save. For more information, see [Launch the UI]({{< link-hextra path="/documentation/setup/ui/launch-ui/#save-changes" >}}), [View access logs in the UI]({{< link-hextra path="/documentation/observability/access-logs/view/#view-access-logs-in-the-ui" >}}), and [Set up virtual keys]({{< link-hextra path="/documentation/llm/cost-controls/virtual-keys/#set-up-virtual-keys-ui" >}}).
 
 ## 🐛 Fixes {#v17-fixes}