Ashfaqbs opened a new issue, #1050: URL: https://github.com/apache/flink-agents/issues/1050
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description `BaseChatModelConnection` and `BaseChatModelSetup` (`python/flink_agents/api/chat_models/chat_model.py`) are pydantic models that inherit `Resource`'s `model_config = ConfigDict(arbitrary_types_allowed=True)`, which does not set `extra=`. Pydantic v2's default for that is `extra="ignore"`. Every concrete chat-model connection/setup (OpenAI, Azure OpenAI, Anthropic, Watsonx, Ollama, Tongyi) accepts `**kwargs: Any` in `__init__` and forwards it straight into `super().__init__(**kwargs)`. **Result:** any unrecognized or misspelled constructor argument is silently swallowed — no error, no warning, no log line. For example: ```python from flink_agents.integrations.chat_models.watsonx.watsonx_chat_model import ( WatsonxChatModelConnection, ) # `api_version` only exists on the Java Watsonx connector; a user copying # Java-side config, or simply mistyping a real field, gets no feedback at all conn = WatsonxChatModelConnection( url="...", api_key="...", project_id="...", api_version="2024-05-01", ) # constructs successfully; `api_version` is silently discarded ``` This also affects config supplied through YAML, since `PythonResourceProvider.provide()` (`python/flink_agents/plan/resource_provider.py:107-121`) forwards resolved YAML config keys as `**kwargs` into the same constructors — so a YAML typo in a chat-model setup/connection block fails exactly the same way: it loads without complaint and the intended setting simply never applies. This runs counter to `code_review.md`'s explicit review lens: *"are invalid user inputs rejected with clear errors that name the invalid value?"* Right now they are not rejected at all. ### Proposed fix Set `extra="forbid"` on `BaseChatModelConnection` and `BaseChatModelSetup`'s `model_config`, so an unknown constructor argument raises a clear pydantic `ValidationError` naming the bad key, instead of vanishing. (Scoped to these two base classes rather than the shared `Resource` base, since some other `Resource` subclasses rely on today's "ignore" behavior in ways that need separate review.) ### Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
