> For the complete documentation index, see [llms.txt](https://docs.lenses.io/latest/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lenses.io/latest/changelog/lenses-6.2/agent.md).

# Agent

Change log for Lenses Agent 6.2.

{% updates format="full" %}
{% update date="2026-09-11" tags="improvements,fixed" %}

## 6.2.8

### Improvements

* **Automatic fallback for older Kafka Connect clusters.** Lenses now detects clusters older than 2.3, and clusters older than 2.5 for connector topics, and falls back to the older APIs on its own. Previously such a cluster made connector monitoring fail while the connection still read as healthy.
* **Connector actions on older Kafka Connect clusters.** Restarting a connector on a cluster older than 3.0 no longer reports an error for a restart that succeeded. Stopping a connector on a cluster older than 3.5, which has no stop API, now pauses it instead of reporting success while doing nothing.
* **Kafka Connect health reports when connectors cannot be listed.** The worker status gains a `degradedReason`, set when the connector poll keeps failing while the worker is still reachable. HQ 6.2.8 shows it on the health dashboard.
* **The Kafka connectivity timeout is configurable.** Test Connection used a fixed three seconds timeout, so a slow but healthy cluster could be reported unreachable. It now comes from the `kafkaConnectivityTimeout` connection property and defaults to twenty seconds. Additionally a timeout is written to the log.
* **Security updates.** Third-party dependencies have been updated to address known security advisories.

### Fixed

* **SQL Processors that Kubernetes never admits now report a warning.** A processor whose pods are blocked before they can start reported `NotRunning` indefinitely, which looked the same as one deliberately scaled to zero. The desired replica count now comes from the Deployment specification rather than its status.
* **Permissions scoped to a named connection are now applied.** Such a permission could never match, because the value it was compared against also carried the connection type.
  {% endupdate %}

{% update date="2026-08-28" tags="improvements,fixed" %}

## 6.2.7

### Improvements

* **Kubernetes security context for SQL Processors.** SQL Processor deployment templates gain two optional properties, **Pod securityContext (raw JSON)** and **Container securityContext (raw JSON)**, which are passed straight through to the pod and container that run the processor — for example `{"runAsUser": 1000}` for the pod and `{"capabilities": {"drop": ["ALL"]}}` for the container. This lets you satisfy cluster security policies without waiting for each individual setting to be exposed. The JSON is checked when the processor is registered, so a malformed value is reported immediately rather than causing a deployment to fail later. Upgrading adds the new properties automatically.
* **Security updates.** Third-party dependencies have been updated to address known security advisories.

### Fixed

* **Record counters no longer turn negative.** TOTAL RECORDS IN and TOTAL RECORDS OUT on the SQL Processor Health screen and the topology view were held as 32-bit numbers, so they wrapped around into large negative values once a processor had handled about 2.1 billion records — roughly three weeks of uptime at 1,200 records a second. The counters are now 64-bit from end to end, including where totals are combined across replicas.
  {% endupdate %}

{% update date="2026-08-19" tags="improvements,fixed" %}

## 6.2.6

### Improvements

* **Broker and topic metric diagnostics.** Metric read failures now name the specific MBean, the Jolokia request method (GET/POST), and the reason reported by the metrics agent — for example an access-policy denial reported as HTTP 403 — instead of an opaque "key not found" error, and are summarised in a single warning per broker for both JMX and Jolokia. Connection-test failures also name the endpoint, making access-policy and method-mismatch misconfiguration far easier to diagnose. A metric that cannot be read no longer aborts the rest of the collection, and credentials in Jolokia URLs are redacted before appearing in any error message.

### Fixed

* **AWS Glue SQL processor deployment (regression).** Deploying a SQL processor against an AWS Glue Schema Registry connection failed with a `missing required property assumeRoleArn` error whenever the AWS connection used Credentials Chain or Access Key authentication rather than Assume Role. SQL processor deployment now works for Glue connections regardless of authentication mode. This regression was introduced in 6.0.1, when AWS assume-role support was added, and went unnoticed because that feature always sets `assumeRoleArn`. Upgrading migrates existing installations automatically.
* **AWS Glue calls could hang under concurrent load.** AWS Glue Schema Registry calls now reliably fail at the configured call timeout instead of occasionally hanging for the full duration of a slow or unresponsive underlying request.
* **Kafka quotas for principals containing special characters.** A client quota for a user or client-id containing a special character — for example the `@` in `jane@corp.com` — was encoded before being sent to Kafka, so it was recorded against a non-existent principal (`jane%40corp.com`) and never took effect, even though it was displayed as active. Such quotas now apply to the correct principal and are shown consistently across the quota list, permission checks and audit log. **After upgrading**, a quota created before this fix is listed under its human-readable name; if one appears missing or duplicated, delete the stale encoded entry and re-create it. Quotas for names using only letters, digits, `.`, `-` and `_` are unaffected.
* **Deployment failures now report the real cause.** A deployment that failed because of a connection or configuration error now reports the underlying reason instead of a misleading "cannot reach cluster" message.
* **Consumer group offset errors are descriptive again.** Failures when retrieving or deleting consumer group offsets now report an internal error with a descriptive message instead of an opaque, undescribed one.
* **AWS Glue format detection.** Automatic topic format detection now recognizes AWS Glue-encoded records and skips invalid Confluent Schema Registry lookups for payloads that are not schema-encoded.
* **Schema Registry health-check logging.** Health checks now record the underlying error when a registry cannot be reached, instead of silently marking it offline.
* **Schema Registry outage reported as server error.** A total Schema Registry outage now returns a 5xx server error instead of being misreported as a 400 client error, so retry logic and alerting keyed on 5xx responses work correctly.
* **Kafka Connect authentication errors surfaced.** A 401/403 from a secured Kafka Connect cluster now surfaces as an authentication/authorization failure instead of being masked as a Lenses-side internal error (500).
* **Connector resume with special-character names.** Resuming a connector whose name contains URL-special characters (`/`, `?`, `#`, space) now targets the correct resource instead of being misrouted.
* **Connector "restart only failed tasks".** The "restart only failed tasks" option is now honored; previously a misnamed query parameter caused every restart to restart all tasks.
  {% endupdate %}

{% update date="2026-07-14" tags="improvements,fixed" %}

## 6.2.5

### Improvements

* **Finer-grained topic permissions**: Topic write access is now split into three independently grantable permissions: topic configuration (`kafka:UpdateTopicDetails`), key/value format (`kafka:UpdateTopicFormat`), and topic description and tags (`kafka:UpdateTopicMetadata`). Lenses enforces each permission separately, so users can be allowed to change only the aspects they need. Existing roles that could update topic details keep all three capabilities.

### Fixed

* SQL Processors now report a `Failed` state when their container image cannot be pulled, instead of appearing to hang.
* Fixed the legacy UI incorrectly reporting a missing SQL execution mode when RBAC denies access to the configuration.
  {% endupdate %}

{% update date="2026-06-24" tags="new" %}

## 6.2.4

**SQL Processors** now support accessing the metadata for records on simple selects and lateral joins. e.g. `SELECT _meta.partition/offset/timestamp/topic.` No support yet for join / group by.
{% endupdate %}

{% update date="2026-06-09" tags="fixed" %}

## 6.2.3

### **Fixed**

* Kafka ACLs. Fixed a bug which block the creation and listing of ACLs if the principal contained more than one `:` separator.
  {% endupdate %}

{% update date="2026-05-29" tags="improvements" %}

## 6.2.2

### Improvements

#### Tunable topic sampling poll parameters

Two new optional config keys let you tune the topic-type-detection sampling consumer per deployment:

* `lenses.interval.topic.sampling.poll-timeout-ms` — per-attempt Kafka poll timeout for the sampling consumer (default `2000`).
* `lenses.interval.topic.sampling.poll-attempts` — maximum poll attempts before giving up (default `3`).

Both defaults match the previously hard-coded values, so existing deployments are unaffected unless you opt in.
{% endupdate %}

{% update date="2026-04-29" tags="improvements,fixed" %}

## 6.2.1

### Improvements

#### Provisioning API in OpenAPI

The Provisioning API is now documented in the OpenAPI specification.

#### Logging

* **`TopicStatsWorker` log noise** during normal operation has been demoted from `INFO` to `DEBUG`, so production logs stay readable.
* **Better diagnostic logging for topic identification** when investigating JSON payload edge cases.

### Fixed

#### SQL on partial JSON payloads

When a SQL query joined or selected from a topic whose value was a JSON object missing some fields, the engine could fail to resolve a union struct type. The engine now matches by **subset** of fields instead, so partial JSON objects no longer fail the query.

#### Topics with unresolved Schema Registry references stay readable

If a topic's value or key referenced a schema that the agent could not yet resolve from the Schema Registry (for example during startup or when the registry was briefly unreachable), reads against that topic could fail. Marshaller construction is now deferred, so the rest of the topic remains readable while the registry catches up.

#### Schema listing no longer shows "NaN"

The Schemas listing in the Agent UI no longer renders "NaN" in place of a name when a schema lacks a numeric identifier.

#### Topic configs page adapts to small viewports

The topic configurations screen now lays out correctly on smaller screen sizes and viewports.
{% endupdate %}

{% update date="2026-04-29" tags="new,fixed" %}

## 6.2.0

### K2K App Metrics

#### **Per-topic throughput breakdown**

The Throughput card now shows bytes/s and records/s per topic for both Source and Target, rather than showing only totals. A search bar appears automatically when there are more than 5 topics.

#### **Lag distribution visibility**

The Health card header now displays P50, P90, and Max lag across all source partitions at a glance. Source partitions with lag above the P90 threshold are highlighted in the partition table, and each lag cell shows the partition's share of total lag on hover.

#### **Studio tab navigation**

Clicking a topic name or offset value in any K2K metrics table now opens a studio tab directly instead of reloading the page. The same applies to K2K app links in the Topics drawer and the error tooltip buttons on the app listing.

### Fixed

#### Enhanced JSON Handling for Union Record Types in SQL

This update for Lenses SQL Processors, dealing with JSON Kafka topics involving unions and nested records, addresses previous query failures. Optional fields missing from JSON are now treated as `null`, exact schema matches are prioritized, and specific error messages indicate the path and expected type of any missing required fields.

#### Kafka data read

Reading Kafka data through a SQL snapshot is based solely on the record context, not the schema known to Lenses. This approach resolves issues where data, written using the schema registry with subject naming strategies like RecordNameStrategy, or TopicRecordNameStrategy, doesn't encounter failures.
{% endupdate %}
{% endupdates %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lenses.io/latest/changelog/lenses-6.2/agent.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
