Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OPIK-628] Fix update LLM provider api key endpoint #901

Merged
merged 1 commit into from
Dec 17, 2024
+9 −9
Merged

[OPIK-628] Fix update LLM provider api key endpoint #901

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions apps/opik-backend/src/main/java/com/comet/opik/api/ProviderApiKeyUpdate.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,16 +7,16 @@
import com.fasterxml.jackson.databind.annotation.JsonNaming;
import jakarta.validation.constraints.NotBlank;
import lombok.Builder;
import lombok.Getter;
import lombok.ToString;

@Builder(toBuilder = true)
@JsonIgnoreProperties(ignoreUnknown = true)
@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
@Getter
Copy link
Collaborator

@andrescrz andrescrz Dec 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that you just want to fix the lack of proper toString implementation.

You could have maintained the previous approach just by changing @Getter annotation by @Data. The advantage is not requiring a custom toString implementation and just relying on @ToString.Exclude. The downside is having a mutable POJO.

You record approach has the reversed pros and cons.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrescrz Unfortunately no:)
Endpoint was failing with {"code":400,"message":"Unable to process JSON"} on deserialization. What's worse, integration tests were ok for the same payload. But in dev or if you run Opik locally with docker-compose issue was reproducible. I tried to play with toString and encryption, but with no result.
The only thing that helped is when I changed regular Java class to record. I double checked locally and with dev deployment before merging.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, probably the issue is that there was no proper setter, so it couldn't be converted from Json to Java POJO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a weird error, Setter doesn't help here too.
And the most disturbing is that our integration tests are passing and can deserialize it properly. Also if you use JsonUtils, then deserialization works fine as well. Issue only happens with dockerised Opik.

public class ProviderApiKeyUpdate {
@ToString.Exclude
@NotBlank
@JsonDeserialize(using = ProviderApiKeyDeserializer.class)
String apiKey;
public record ProviderApiKeyUpdate(
@NotBlank @JsonDeserialize(using = ProviderApiKeyDeserializer.class) String apiKey
){

@Override
public String toString() {
return "ProviderApiKeyUpdate{}";
}
}
2 changes: 1 addition & 1 deletion apps/opik-backend/src/main/java/com/comet/opik/domain/LlmProviderApiKeyService.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,7 +116,7 @@ public void updateApiKey(@NonNull UUID id, @NonNull ProviderApiKeyUpdate provide

repository.update(providerApiKey.id(),
workspaceId,
providerApiKeyUpdate.getApiKey(),
providerApiKeyUpdate.apiKey(),
userName);

return null;
Expand Down
Loading