Skip to content

[agentbricks] Say why endpoint invoke <app> can't find the app - #834

Open
elainewang-db wants to merge 1 commit into
databricks:mainfrom
elainewang-db:agentbricks-invoke-app-url-error
Open

elainewang-db wants to merge 1 commit into
databricks:mainfrom
elainewang-db:agentbricks-invoke-app-url-error

Conversation

@elainewang-db

Copy link
Copy Markdown
Contributor

What

agentbricks endpoint invoke <app> now says why it can't reach an app instead of always printing "Could not resolve a URL for Databricks App '...'":

  • App not found: No Databricks App named 'agent-bricks-x' in the workspace for profile 'ml'., with a hint to pass the right workspace's profile with -p and to list deployments.
  • Any other apps get failure (signed-out profile, network, bad host): the CLI's own message plus the sign-in hint, via AppsClient.find's existing error.
  • App with no URL yet: says so and points at agentbricks deployments get.

Why

get_app_url returns None for any failed apps get and drops its stderr. While manually testing 0.8.0, invoking an app from a shell where Agent Bricks fell back to another workspace's profile gave only "Could not resolve a URL", with nothing about which workspace it searched or why it failed.

Changes

  • New AppsClient.app_url(name), built on find. EndpointService._resolve_endpoint uses it.
  • get_app_url is unchanged; deploy still uses it.

Testing

  • New apps_client_test.py cases: the URL, a missing app with and without a profile, another apps get failure keeping its stderr, and an empty or missing URL. The endpoint service, loadtest and CLI tests now mock app_url.
  • Unit suite: 2753 passed. ruff check, ruff format --check and ty check are clean.
  • Manual: agentbricks -p ml endpoint invoke agent-bricks-lg-ewrel0802108 ... against a deleted app prints the new not-found error and hint.

Related: #694 makes the profile choice itself consistent; this PR makes a failed lookup say what happened either way.

This pull request and its description were written by Isaac.

`endpoint invoke <app>` looked the app up with `get_app_url`, which
returns None for any failed `apps get` and drops its stderr, so every
failure read "Could not resolve a URL for Databricks App '...'": a
signed-out profile, a network error, and an app deployed to another
workspace all looked the same.

Resolve the URL through a new `AppsClient.app_url`, built on `find`:
a missing app names the profile it was looked up with and points at
`-p`, any other failure keeps the CLI's message and the sign-in hint
`find` already gives, and an app without a URL says so. Deploy keeps
using `get_app_url`.

Co-authored-by: Isaac <no-reply@databricks.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant