attachment_urls on dial_deployment tools fail on file:data:: references #518

QuickApps version

development

What steps will reproduce the bug?

1. Configure a Quick App with a DIAL deployment tool that declares a file-reference parameter (e.g. attachment_urls).
2. Attach a large document (multi-MB) to the conversation.
3. Send a request that causes the LLM to call the DIAL deployment tool with that file attached.
4. The LLM follows the tool-call-file-parameter-formatting skill (v1.1, changed in feat: add new way of pushing data to MCP #479) and emits the new default data:: prefix: e.g. "attachment_urls": ["file:data::files//document.docx"]
5. The file-argument transformer expands the reference into a full inline data: URI, but the attachment resolver only accepts DIAL and http(s) URLs and raises InvalidToolCallParameterException.
6. The inlined base64 payload is the core problem: it pollutes both the LLM context and the logs. When the resolver rejects the value, the orchestrator's retry re-injects the error (which itself carries the payload) into the next LLM call, pushing the context past the model's limit and the request fails with 400.

Note: a small attachment can surface the same InvalidToolCallParameterException directly; the context-window overflow on step 6 appears with large files.

What is the expected behavior?

data: URIs should be accepted on DIAL deployment tools the same way they are on MCP tools (MCP servers decode the inline content directly). Since a deployment target needs a resolvable URL, the attachment resolver should handle data: URIs by decoding the inline content and promoting it to a durable file in the caller's DIAL storage - the same path used for external URLs - and then pass the resulting file URL to the deployment.

Concretely:

A file:data:: reference in attachment_urls (or any file-reference parameter) resolves successfully instead of raising InvalidToolCallParameterException.
The multi-MB inline payload is consumed exactly once during resolution and never injected into the LLM context or written to logs.
The deployment receives a normal, fetchable file URL and the call completes as if the file had been referenced by its DIAL URL from the start.

What do you see instead?

See steps to reproduce

Additional information

Suggested fix: accept data: URIs in the attachment resolver by decoding the payload once and promoting it to a durable DIAL file (the existing external-URL promotion path), then passing the resulting file URL to the deployment. As a hardening measure, error messages returned to the LLM should never carry raw inline payloads, and data-URI URLs should be collapsed to data:, in logs.