joeyutong opened a new issue, #857: URL: https://github.com/apache/flink-agents/issues/857
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description Flink Agents currently binds the current action metric group to resources when users call `RunnerContext#getResource(...)` / `RunnerContext.get_resource(...)`. This works for resources implemented in the same language as the action, but the cross-language resource wrappers do not consistently propagate the metric group to the actual resource on the other side of the Java/Python boundary. Current behavior, in simplified form: - Java action -> Python resource: the Java `Python*` wrapper receives the action metric group, but the underlying Python resource does not necessarily receive `set_metric_group(...)`. - Python action -> Java resource: the Python `Java*` wrapper receives the action metric group, but the underlying Java resource is fetched through the Java resource context/cache path rather than the Java runner-context path, so it does not necessarily receive `setMetricGroup(...)`. This is acceptable for metrics that are fully owned and recorded by the action layer. For example, token metrics can still be recorded under an action/model scope if the action extracts usage fields from the response and records counters on the local wrapper. However, some features need the metric group to reach the actual provider/resource implementation. Examples: - provider-specific metric dimensions such as `serviceUrl`, `serviceType`, tenant, deployment, or endpoint; - chat/embedding model connections that wrap the metric group before recording token usage; - vector stores, embedding models, long-term memory, or MCP resources that record latency, request count, error count, cache hit/miss, or backend-specific metrics internally; - nested resource calls where the resource, not the action, owns the operation semantics and should own the metric scope; - consistent observability behavior between same-language resources and cross-language resources. A possible improvement is to make cross-language resource wrappers propagate metric group binding to the underlying resource when `setMetricGroup(...)` / `set_metric_group(...)` is called, or to expose an adapter-level metric-group binding hook for the underlying Java/Python object. The implementation should also define metric ownership clearly to avoid double-counting when action-level metrics and provider-level metrics both observe the same model response. ### Are you willing to submit a PR? - [ ] 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]
