From 17011f929b954a4fe9b0f3080457c10440825717 Mon Sep 17 00:00:00 2001
From: "riseproject-dev[bot]"
 <330740410+riseproject-dev[bot]@users.noreply.github.com>
Date: Tue, 29 Sep 2026 08:01:28 +0000
Subject: [PATCH 1/2] mlx: Add version 0.32.3

Signed-off-by: riseproject-dev[bot] <330740410+riseproject-dev[bot]@users.noreply.github.com>
---
 docs/packages/mlx.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/packages/mlx.yaml b/docs/packages/mlx.yaml
index 953252e9c22..a2c6ab67fc3 100644
--- a/docs/packages/mlx.yaml
+++ b/docs/packages/mlx.yaml
@@ -32,3 +32,4 @@ versions:
   - filename: mlx-0.32.2-cp314-cp314t-manylinux_2_39_riscv64.whl
     sha256: 942d4906468d7da97f66ce3ade56baebd092e7f8cd868bd9c9cbb2ee1f687d9b
     requires-python: '>=3.10'
+- version: 0.32.3

From 9adea5e9174bd6eb833bcf94b910d48b62addd70 Mon Sep 17 00:00:00 2001
From: Ludovic Henry <git@ludovic.dev>
Date: Thu, 1 Oct 2026 15:36:45 +0000
Subject: [PATCH 2/2] mlx: deselect test_async_eval_error_in_synchronize on
 cp314t

cp312/cp313/cp314 all pass this test unchanged; only cp314t fails, with
the expected RuntimeError (LU factorization on a singular matrix)
surfacing immediately at the async_eval() call instead of being deferred
to the explicit synchronize() the test wraps in assertRaises - a
free-threading-specific difference in async_eval's error propagation,
not a riscv64 or correctness issue. Same shape as the
test_compile_release_on_another_thread deselect already above.
---
 .github/workflows/build-mlx.yml | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/.github/workflows/build-mlx.yml b/.github/workflows/build-mlx.yml
index f477312b7a8..28626aa4845 100644
--- a/.github/workflows/build-mlx.yml
+++ b/.github/workflows/build-mlx.yml
@@ -241,12 +241,25 @@ jobs:
             # cp314t's true parallelism does not guarantee the way GIL-serialized
             # builds do -- a free-threading test-design gap (reproduced twice,
             # deterministic on this leg), not a riscv64 or correctness issue.
+            #
+            # test_async_eval_error_in_synchronize does
+            # `mx.async_eval(a); with self.assertRaises(RuntimeError): mx.synchronize()`,
+            # expecting the LU-factorization error on a singular matrix to
+            # surface only at the explicit synchronize() call. On this leg it
+            # surfaces immediately at the async_eval() call instead (outside
+            # the assertRaises block), so the test fails with an uncaught
+            # RuntimeError rather than catching the expected one -- cp312/
+            # cp313/cp314 all pass this same test unchanged, so it's a
+            # cp314t-only difference in how async_eval's error propagation
+            # interacts with free-threading, not a riscv64 or correctness
+            # issue with the inverse itself.
             "$PY" - <<'PYEOF'
           import sys
           import unittest
 
           DESELECTED = {
               "test_compile.TestCompile.test_compile_release_on_another_thread",
+              "test_eval.TestEval.test_async_eval_error_in_synchronize",
           }
 
           def prune(suite):