mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-08-18 16:02:10 +00:00
Ruben Fiszel
18ae0bdfbf
* fix: explain duckdb failures caused by job isolation Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: apply the isolation policy to the schema-sync pre-pass Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: bump ee ref for the out-of-memory hint wording Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: bump the bundled DuckDB engine to 1.5.5 The 1.5.5 duckdb crate no longer hands back a 96-bit `rust_decimal`, so a DECIMAL wider than that renders instead of panicking inside an `extern "C"` frame — which, being unable to unwind, aborted the whole worker process and left the job running as a zombie. `SELECT '1234567890123456789012345678.9012345678'::DECIMAL(38, 10)` was enough. Adapting to the crate's API: `Value` is now `#[non_exhaustive]` and gained `UHugeInt` and `Geometry`, and `rust_decimal` became an optional feature that the `decimal`/`numeric` argument path still needs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: address review findings on the duckdb bump Run the FFI crate's own tests in CI: it is excluded from the workspace, so the `cargo test --all` in backend-test never reached them and the new guard against the worker-aborting DECIMAL would not have run. build_dev.sh now honors a caller-pinned CARGO_TARGET_DIR so the test build reuses that compile instead of building the bundled engine a second time. Also pin UHUGEINT rendering, and correct the rust_decimal rationale — `Decimal::new` is public without the feature, so the reason is that the feature reproduces the exact binding the crate used to derive, not that nothing else can. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: address review nits on the duckdb bump Name the unsupported DuckDB type rather than dumping the value, which may be arbitrarily large or hold data that does not belong in an error message, and say which column it came from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: pin the ee ref to the narrowed duckdb extension allowlist Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat: keep duckdb spilling behind the local-filesystem fence * chore: repin the duckdb fork after adding the reset-test exclusion * docs: stop claiming the duckdb patch has been filed upstream * docs: point the backend duckdb bullet at the fork's rationale * fix: place lock_temp_directory so no existing struct member moves * fix: skip the extension-load guard when the repo is unreachable * refactor: trim the fork comments and fail the extension guard in CI * chore: repin the duckdb fork onto upstream duckdb-rs main * fix: keep the engine patch applying on a CRLF checkout * docs: link the upstream issue tracking the underlying problem * chore: repin the duckdb fork onto the patch as filed upstream Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: update ee-repo-ref to 88568d11162ffa11723e7955e613224bab4f0568 This commit updates the EE repository reference after PR #720 was merged in windmill-ee-private. Previous ee-repo-ref: 22f075c1164d9dd5a3ba92d682905aabd071d273 New ee-repo-ref: 88568d11162ffa11723e7955e613224bab4f0568 Automated by sync-ee-ref workflow. * chore: repin the duckdb fork onto the cmake/fmt build fix Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test: pin the immutability half of lock_temp_directory The spill test proves the exemption works; nothing proved the lock that makes it sound. A rebase could drop the refusals and leave every other tripwire green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: windmill-internal-app[bot] <windmill-internal-app[bot]@users.noreply.github.com>