Skip to content

v2.2.0 — diagnose refused DIAL file reads

Choose a tag to compare

View all tags
@photonn photonn released this 20 Aug 12:55
· 32 commits to main since this release
v2.2.0
ce3368f

v2.1.0 fixed the shape of DIAL file URLs. This release deals with what surfaces
underneath it: a refused read, which is an identity problem wearing a URL's clothes.

The failure

Failed to download the image from DIAL file storage:
Client error '403 Forbidden' for url
'http://dial-core.dial.svc.cluster.local/v1/files/PZh2…/appdata/gpt-image-1.5-square/images/027b….png'

Nothing there is actionable — not for the agent, which will retry or hallucinate another
URL, and not really for the operator either. The URL is correct. The credentials are the
problem.

DIAL file storage is per-user, and inside appdata it is also per-deployment: credentials
reach their own bucket and their own appdata folder, nothing else. An image generated by
an image deployment lands in {user-bucket}/appdata/{that-deployment}/…, so a server
falling back to its own DIAL_API_KEY cannot read it, and neither can a caller that is
not that deployment or the bucket's owner.

What a refusal says now

401/403/404 on a read raises DialConfigError naming the identity used, the bucket it
owns, the bucket the file is in, the appdata deployment that owns it, and the ways out:

DIAL Core refused this file (403). This read ran as the server's DIAL_API_KEY, which owns
bucket SERVERBU…, while the file is in bucket PZh2M4YF…. The file also sits in the
appdata folder of the 'gpt-image-1.5-square' deployment, which only that deployment and
the user who owns the bucket may read — this server is neither unless DIAL forwards the
end user's own credentials to it. Fix it at the source: have the orchestrator copy the
image into storage these credentials can reach…

New tool: get_dial_storage_info

Read-only. Reports the identity this server has on the current request, the bucket it
owns and its appdata path — so "can this server read that URL?" is a question you answer
by looking, not by triggering a failure. If the bucket it reports is not the bucket in the
image URL, no URL fix will help.

Not added

Retrying a refused read under the server's key after the caller's credentials were denied.
It would "fix" this class of failure by turning an authorization error into privilege
escalation, and it is now written down in CLAUDE.md as a thing not to do.

Suite is 146 tests, green.

Assets 2
Loading