Skip to content

Retry transient Files API errors in fs commands on UC Volumes - #7252

Open
denik wants to merge 2 commits into
mainfrom
denik/filer-files-api-retry
Open

denik wants to merge 2 commits into
mainfrom
denik/filer-files-api-retry

Conversation

@denik

@denik denik commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Changes

Pass a retrier to the idempotent Files API calls in libs/filer/files_client.go: file/directory metadata (Stat, the parent check in Write), ReadDir, Read and Mkdir. Retried statuses are 408/429/502/503/504, the same list the files/v2 upload engine uses for its control-plane calls, with a 5 minute budget per call. Uploads (body can't be replayed) and deletes (a retry after a server-side success would turn into a 404) are unchanged.

Why

files/v2 calls are not retried unless a retrier is passed per call. Since the filer moved to files/v2 in #6018, a transient error like GCP is temporarily unavailable; try again later. fails the command immediately, where the old SDK client retried 429/503. This shows up as the GCP flakes of integration/cmd/fs.TestFsCpFileToNonExistentDir (CI dashboard error 3017).

The status code of those GCP errors isn't in the CI logs; TEMPORARILY_UNAVAILABLE is normally a 503. 500 is deliberately not retried, matching both SDKs.

Dashboard: errors 1140 (40 runs), 3017, 12, 1194, 1166; tests integration/cmd/fs.TestFsCpFileToNonExistentDir/uc-volumes_to_uc-volumes, integration/cmd/fs.TestFsCpFileToDir/uc-volumes_to_local, integration/cmd/fs.TestFsCpDirToDirFileNotOverwritten/uc-volumes_to_uc-volumes.

# 1140, TestFsCpDirToDirFileNotOverwritten/uc-volumes_to_uc-volumes (azure)
Error:      	Received unexpected error:
            	databricks-api error: Azure is temporarily unavailable; try again later.

# 3017, TestFsCpFileToNonExistentDir/uc-volumes_to_uc-volumes (gcp)
cp_test.go:395:  error: databricks-api error: GCP is temporarily unavailable; try again later.

# 1166, TestFsCpFileToDir/uc-volumes_to_local (azure); same empty message in 1194
cp_test.go:176:  error: databricks-api error:

Tests

New unit tests: a 503 followed by success is retried, a 500 is not. go test ./libs/filer/... ./cmd/fs/... and the cmd/fs acceptance tests pass.

This pull request and its description were written by Isaac.

@eng-dev-ecosystem-bot

eng-dev-ecosystem-bot commented Oct 29, 2026 •

Copy link
Copy Markdown
Collaborator

Integration test report

Commit: e5be795

Run: 41435792125

Env ✅​pass 🙈​skip Time
✅​ aws linux-2core-8gb 281 15 5:37
✅​ aws-windows-latest-4core-16gb 283 13 3:33
✅​ azure linux-2core-8gb 280 15 5:41
✅​ azure-windows-latest-4core-16gb 282 13 3:32
✅​ gcp linux-2core-8gb 281 15 5:03
✅​ gcp-windows-latest-4core-16gb 283 13 3:32
Top 3 slowest tests (at least 2 minutes):
duration env testname
3:27 aws-windows-latest-4core-16gb TestAccept
3:26 gcp-windows-latest-4core-16gb TestAccept
3:26 azure-windows-latest-4core-16gb TestAccept

denik and others added 2 commits November 2, 2026 11:13
files/v2 calls are not retried without a per-call retrier, so since #6018
a transient 503/429/502/504 from the Files API failed fs commands on UC
Volumes outright. Retry reads, metadata checks, listing and mkdir; uploads
and deletes are left alone.

Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
@denik
denik force-pushed the denik/filer-files-api-retry branch from d0752f4 to e5be795 Compare November 2, 2026 11:17
@denik
denik marked this pull request as ready for review November 2, 2026 12:43
@denik
denik requested review from a team as code owners November 2, 2026 12:43

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.

2 participants