Deployment 0.3.69#317
Merged
Merged
Conversation
It's not necessary, and it might be causing the entire workflow to fail
📝 WalkthroughWalkthroughUpdates build and publish workflows, adds package metadata and version bumps, changes Tower catalog routing to detect and cache catalog type, and adds conditional ChangesCI/Build Workflow Updates
Tower catalog routing
UV link mode handling
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
tests/tower/test_tables.py (1)
174-178: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMissing test for the
describe_catalogexception/failure path.
describe_catalog_api_synchere is only stubbed to returnNoneor aDescribeCatalogResponse; there's no test where it raises (simulating a network error or timeout), which is exactly theexcept Exceptionbranch in_describe_tower_catalog_type(src/tower/_storage.py, lines 142-156). Since this PR's stated goal is fixing credential-vending decisions for BYO/S3 tables, covering the "Tower API call fails" fallback-to-PyIceberg-config path would meaningfully harden this critical path.def test_string_catalog_falls_back_when_describe_raises(monkeypatch): ... def describe_catalog_api_sync(name, client, environment): raise RuntimeError("boom") ... # assert fallback to _has_pyiceberg_catalog_config / load_catalog🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/tower/test_tables.py` around lines 174 - 178, Add a test that covers the `describe_catalog` failure path in the Tower table catalog flow. In `describe_catalog_api_sync`, simulate an exception (for example a network/timeout failure) instead of only returning `None` or a `DescribeCatalogResponse`. Verify `_describe_tower_catalog_type` in `src/tower/_storage.py` takes the `except Exception` branch and falls back to the PyIceberg catalog config path by checking `_has_pyiceberg_catalog_config` / `load_catalog` behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/tower/_storage.py`:
- Around line 132-173: The Tower catalog lookup in _describe_tower_catalog_type
can hang indefinitely because describe_catalog_api.sync is called without a
bounded timeout, and failures are not cached so repeated loads keep retrying.
Update _describe_tower_catalog_type to pass a finite timeout through the Tower
client call path (via _env_client or the sync invocation) and make sure both
exception and ErrorModel fallback paths store a negative result in
_catalog_type_cache for the (ctx.tower_url, name, environment) key, so repeated
failures do not reissue the request.
---
Nitpick comments:
In `@tests/tower/test_tables.py`:
- Around line 174-178: Add a test that covers the `describe_catalog` failure
path in the Tower table catalog flow. In `describe_catalog_api_sync`, simulate
an exception (for example a network/timeout failure) instead of only returning
`None` or a `DescribeCatalogResponse`. Verify `_describe_tower_catalog_type` in
`src/tower/_storage.py` takes the `except Exception` branch and falls back to
the PyIceberg catalog config path by checking `_has_pyiceberg_catalog_config` /
`load_catalog` behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d7819fb6-37d0-4419-a7fc-20066b3bb5b1
📒 Files selected for processing (6)
.github/workflows/build-binaries.yml.github/workflows/publish-npm.ymlcrates/tower-package/Cargo.tomlsrc/tower/_storage.pysrc/tower/_tables.pytests/tower/test_tables.py
💤 Files with no reviewable changes (1)
- .github/workflows/publish-npm.yml
socksy
approved these changes
Jul 3, 2026
There was a problem hiding this comment.
🧹 Nitpick comments (1)
tests/tower/test_storage.py (1)
186-251: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueSolid coverage of timeout + cooldown + recovery behavior.
Test logic correctly traces through
_describe_tower_catalog_type's failure-cache/cooldown/recovery paths and matches the upstream contract insrc/tower/_storage.py. One minor note: assertingclient._timeout(Line 201) relies on a private attribute of the generatedopenapi-python-clientClient. This works but is coupled to library internals rather than a public accessor.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/tower/test_storage.py` around lines 186 - 251, The test for _describe_tower_catalog_type is asserting the generated Client’s private _timeout attribute, which couples the test to openapi-python-client internals. Update the timeout assertion to use a public-facing behavior or observable effect from describe_catalog_api.sync instead, while keeping the same coverage for the timeout/cooldown/recovery flow in _describe_tower_catalog_type.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@tests/tower/test_storage.py`:
- Around line 186-251: The test for _describe_tower_catalog_type is asserting
the generated Client’s private _timeout attribute, which couples the test to
openapi-python-client internals. Update the timeout assertion to use a
public-facing behavior or observable effect from describe_catalog_api.sync
instead, while keeping the same coverage for the timeout/cooldown/recovery flow
in _describe_tower_catalog_type.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e5a4e320-bbc2-4c6e-9a25-7579495adbb8
📒 Files selected for processing (2)
src/tower/_storage.pytests/tower/test_storage.py
🚧 Files skipped from review as they are similar to previous changes (1)
- src/tower/_storage.py
* fix(tower-uv): use copy link mode when no cache dir is set When no explicit cache dir is configured, uv uses its default cache (~/.cache/uv). In containerized or sandboxed execution that default often lives on a different filesystem than the target venv, so uv can't hardlink across the two (EXDEV) and prints a noisy "Failed to hardlink files; falling back to full copy" warning into the setup logs. Force UV_LINK_MODE=copy on the sync/pip/run commands in that case so the warning is suppressed (uv was already falling back to copy anyway). Callers that pass an explicit cache dir on the same filesystem as the venv are unaffected and keep fast hardlink/clone. * docs(tower-uv): simplify apply_link_mode comment
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
crates/tower-uv/src/lib.rs (1)
305-343: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
venv()should use the shared link-mode override too.uv venvstill seeds packages from the cache, so skippingself.apply_link_mode(&mut cmd)here can leave the hardlink-attempt warning in place whencache_diris unset. Add the same call used bysyncandrunbeforespawn().🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/tower-uv/src/lib.rs` around lines 305 - 343, The venv() command builder in tower-uv::lib::UV should also apply the shared link-mode override before spawning uv, since uv venv can still trigger the hardlink fallback warning when cache_dir is unset. Update the venv() method to call apply_link_mode on the Command just like the sync and run paths do, so the UV_LINK_MODE copy setting is consistently applied in all uv invocations.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@crates/tower-uv/src/lib.rs`:
- Around line 305-343: The venv() command builder in tower-uv::lib::UV should
also apply the shared link-mode override before spawning uv, since uv venv can
still trigger the hardlink fallback warning when cache_dir is unset. Update the
venv() method to call apply_link_mode on the Command just like the sync and run
paths do, so the UV_LINK_MODE copy setting is consistently applied in all uv
invocations.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 85e86252-f2f9-4b00-853c-83cfcd4ffcca
📒 Files selected for processing (1)
crates/tower-uv/src/lib.rs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
New Features
Bug Fixes
Chores
Summary by CodeRabbit
New Features
Bug Fixes