Compatibility Issue with ForwardingArtifactService and Custom Artifact Services

[KoveSec]

The ADK framework has a critical interface compatibility issue where custom implementations of BaseArtifactService that extend the interface with additional parameters (like tool_context for traceability) fail at runtime when used through ADK's internal ForwardingArtifactService. This creates a fundamental conflict between ADK-compliant design (adding context for traceability) and ADK's internal forwarding mechanisms.

To Reproduce

Steps to reproduce the behavior:

Create a custom artifact service that extends BaseArtifactService.save_artifact() with additional parameters (e.g., tool_context)
Use this service in an ADK application with AgentTool or other components that create ForwardingArtifactService wrappers
Call the artifact service through the ADK tooling infrastructure
See error: ForwardingArtifactService.save_artifact() got an unexpected keyword argument 'tool_context'
Expected behavior

The ADK framework should either:

Support interface extensions in forwarding services by passing through additional parameters
Prevent interface extensions that break compatibility at compile/initialization time
Provide clear documentation about forwarding service limitations
Offer alternative mechanisms for context traceability that work with the forwarding architecture
Screenshots

Error message:

❌ 16:15:58 | ERROR | Failed to save artifact analyze_latest_scan_results_output_20250702_231558.txt for session f18f5985-b867-488f-9145-badf7c683bc5: ForwardingArtifactService.save_artifact() got an unexpected keyword argument 'tool_context'

Desktop (please complete the following information):

OS: Windows 11 Pro
Python version: 3.12.11
ADK version: 1.5.0
Model Information: gemini-2.5-flash
This issue is framework-level and not model-specific.

Additional context

The root cause is in agent_tool.py:116 where ForwardingArtifactService is created, but it only supports the base interface defined in base_artifact_service.py:27-35 .

This creates a problematic situation where:

Custom services work when called directly
The same services fail when called through ADK's internal tooling
Developers trying to be "ADK-compliant" by adding context traceability are penalized
The error only manifests at runtime in specific execution paths
This is particularly problematic because the ADK documentation encourages context traceability, but the framework's own forwarding mechanism breaks when developers implement it.

Suggested Solutions:

Modify ForwardingArtifactService to pass through additional keyword arguments
Add interface validation at service registration time
Provide official ADK patterns for context traceability that work with forwarding services
Document the forwarding service limitations clearly

[llalitkumarrr]

Hello @KoveSec

Could you please try the latest ADK version and check if the issue is resolved? If not, could you share a minimal reproducible example so we can investigate further?