fix: resolve UnsupportedFieldAttributeWarning for secret_registry field

[neubig]

Summary

This PR fixes the UnsupportedFieldAttributeWarning errors appearing in production logs for the secret_registry field in ConversationState.

Problem

The following warnings were appearing in Datadog logs in production:

UnsupportedFieldAttributeWarning: The 'serialization_alias' attribute with value 'secret_registry' was provided to the `Field()` function, which has no effect in the context it was used.

UnsupportedFieldAttributeWarning: The 'validation_alias' attribute with value AliasChoices(choices=['secret_registry', 'secrets_manager']) was provided to the `Field()` function, which has no effect in the context it was used.

These warnings occur because ConversationState inherits from OpenHandsModel, which is involved in discriminated union serialization. In Pydantic 2.x, validation_alias, serialization_alias, and frozen attributes when used directly in Field() don't work correctly in union type contexts. The warning explicitly states these are "field-specific metadata, and can only be attached to a model field using Annotated metadata or by assignment."

Root Cause

This was introduced in c6ebf3d (PR #969) when adding alias support for backward compatibility with secrets_manager field name.

Solution

• Remove validation_alias and serialization_alias from the Field() definition
• Add a model_validator(mode='before') to handle the legacy secrets_manager key for backward compatibility
• The serialization_alias was redundant anyway since it matched the field name

Testing

• Verified that the warning no longer appears when importing ConversationState
• Confirmed backward compatibility: data with secrets_manager key is still correctly mapped to secret_registry
• All existing tests pass:
  • tests/sdk/conversation/test_conversation_secrets_constructor.py ✅
  • tests/sdk/conversation/test_secrets_manager.py ✅

@neubig can click here to continue refining the PR

---

Agent Server images for this PR

• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server

Variants & Base Images

Variant	Architectures	Base Image	Docs / Tags
java	amd64, arm64	eclipse-temurin:17-jdk	Link
python	amd64, arm64	nikolaik/python-nodejs:python3.12-nodejs22	Link
golang	amd64, arm64	golang:1.21-bookworm	Link

Pull (multi-arch manifest)

# Each variant is a multi-arch manifest supporting both amd64 and arm64
docker pull ghcr.io/openhands/agent-server:612cb8c-python

Run

docker run -it --rm \
  -p 8000:8000 \
  --name agent-server-612cb8c-python \
  ghcr.io/openhands/agent-server:612cb8c-python

All tags pushed for this build

ghcr.io/openhands/agent-server:612cb8c-golang-amd64
ghcr.io/openhands/agent-server:612cb8c-golang_tag_1.21-bookworm-amd64
ghcr.io/openhands/agent-server:612cb8c-golang-arm64
ghcr.io/openhands/agent-server:612cb8c-golang_tag_1.21-bookworm-arm64
ghcr.io/openhands/agent-server:612cb8c-java-amd64
ghcr.io/openhands/agent-server:612cb8c-eclipse-temurin_tag_17-jdk-amd64
ghcr.io/openhands/agent-server:612cb8c-java-arm64
ghcr.io/openhands/agent-server:612cb8c-eclipse-temurin_tag_17-jdk-arm64
ghcr.io/openhands/agent-server:612cb8c-python-amd64
ghcr.io/openhands/agent-server:612cb8c-nikolaik_s_python-nodejs_tag_python3.12-nodejs22-amd64
ghcr.io/openhands/agent-server:612cb8c-python-arm64
ghcr.io/openhands/agent-server:612cb8c-nikolaik_s_python-nodejs_tag_python3.12-nodejs22-arm64
ghcr.io/openhands/agent-server:612cb8c-golang
ghcr.io/openhands/agent-server:612cb8c-java
ghcr.io/openhands/agent-server:612cb8c-python

About Multi-Architecture Support

• Each variant tag (e.g., 612cb8c-python) is a multi-arch manifest supporting both amd64 and arm64
• Docker automatically pulls the correct architecture for your platform
• Individual architecture tags (e.g., 612cb8c-python-amd64) are also available if needed

[enyst]

LGTM

However, I'm not sure about the agent's explanation, I might be missing something there:

• since this PR, OpenHandsModel doesn't/shouldn't matter, BaseModel would do anyway: #1555

But it's just unclear to me about the explanation, we could always do it this way instead I think