You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have AKHQ running on version 25.0 this is connected out to Confluent Cloud. There seems to be an issue with how the 'Topics' sections is trying to deserialize data. I think this could be related to Issue #1890 as well.
Log when trying to load topic data:
2024-08-28 19:55:09,167 WARN io-executor-thread-4 org.akhq.log.access [Date: 2024-08-28T19:55:08.920750149Z] [Duration: 246 ms] [Url: GET /api/dev/schema/id/100130] [Status: 409]
Log when working the 'Schema Registry' tab of AKHQ:
2024-08-28 19:57:03,878 INFO io-executor-thread-11 org.akhq.log.access [Date: 2024-08-28T19:57:03.468870238Z] [Duration: 409 ms] [Url: GET /api/dev/schema/%3A.sto%3A<TOPIC_NAME>-value/version] [Status: 200]
You can see when withing the Schema registry tab the GET request is not using the schema ID but rather the full name and is able to properly obtain the schema. In the Topic section the data is returned but is not deserialized.
Topic View:
Schema Registry View:
This can be demonstrated when calling the schema registry apis directly.
Correct Format:
.confluent.cloud/contexts/.sto/schemas/ids/100130
This call results in the schema being returned successfully.
AKHQ Schema Registry Section Call:
.confluent.cloud/subjects/:.sto:<TOPIC_NAME>/versions/1
This results in the schema being returned successfully.
AKHQ Topic Section Call and Problem from what I can tell:
.confluent.cloud/schemas/ids/100130
{
"error_code": 40403,
"message": "schema not found"
}
This call results in a 404.
The text was updated successfully, but these errors were encountered:
I'm not really familiar with the schema contexts you are mentioning. It means that calls to to your Confluent Cloud schema registry can be prefixed by /contexts/ to tell the context you are using, right ?
How AKHQ should handle these contexts for you ?
What I am showing above is that AKHQ is not correctly searching for schemas because it is not accounting for context information. When schema contexts are being used the schema ID is not globally unique it is unique to the context.
Currently we have AKHQ running on version 25.0 this is connected out to Confluent Cloud. There seems to be an issue with how the 'Topics' sections is trying to deserialize data. I think this could be related to Issue #1890 as well.
Specifically, I believe it is related to how within Confluent Cloud schema registry is typically set up to use schema contexts. When trying to deserialize topic data, AKHQ is not properly using context and is trying to use the schema ID instead. https://github.com/tchiotludo/akhq/blob/dev/src/main/java/org/akhq/controllers/SchemaController.java#L160
Log when trying to load topic data:
2024-08-28 19:55:09,167 WARN io-executor-thread-4 org.akhq.log.access [Date: 2024-08-28T19:55:08.920750149Z] [Duration: 246 ms] [Url: GET /api/dev/schema/id/100130] [Status: 409]
Log when working the 'Schema Registry' tab of AKHQ:
2024-08-28 19:57:03,878 INFO io-executor-thread-11 org.akhq.log.access [Date: 2024-08-28T19:57:03.468870238Z] [Duration: 409 ms] [Url: GET /api/dev/schema/%3A.sto%3A<TOPIC_NAME>-value/version] [Status: 200]
You can see when withing the Schema registry tab the GET request is not using the schema ID but rather the full name and is able to properly obtain the schema. In the Topic section the data is returned but is not deserialized.
Topic View:
Schema Registry View:
This can be demonstrated when calling the schema registry apis directly.
Correct Format:
.confluent.cloud/contexts/.sto/schemas/ids/100130
This call results in the schema being returned successfully.
AKHQ Schema Registry Section Call:
.confluent.cloud/subjects/:.sto:<TOPIC_NAME>/versions/1
This results in the schema being returned successfully.
AKHQ Topic Section Call and Problem from what I can tell:
.confluent.cloud/schemas/ids/100130
{
"error_code": 40403,
"message": "schema not found"
}
This call results in a 404.
The text was updated successfully, but these errors were encountered: