@@ -198,7 +198,7 @@ writes the same Arrow IPC block format as native shuffle, so direct read applies
 - Off-heap mode gets `CometUnifiedShuffleMemoryAllocator`, an ordinary Spark `MemoryConsumer`
   drawing from `spark.memory.offHeap.size`. When it cannot acquire a page the writer spills to
   disk. An allocation that loses the task's entry in Spark's execution pool while it waits
-  ([SPARK-59827](https://issues.apache.org/jira/browse/SPARK-59827)) is retried a few times before
+  ([SPARK-59444](https://issues.apache.org/jira/browse/SPARK-59444)) is retried a few times before
   it counts as a page that could not be acquired.
 - On-heap mode gets `CometUnboundedShuffleMemoryAllocator`, which keeps no budget and so never
   refuses a page. Nothing bounds these allocations, and memory pressure never triggers a spill.
 
@@ -140,12 +140,12 @@ same task like any other allocation. A page or pointer array allocation that wai
 memory can wake up to find the task's entry gone from Spark's execution pool, because another
 consumer of the task released its last bytes in the meantime, and Spark then throws a
 `NoSuchElementException` ("key not found") instead of a grant
-([SPARK-59827](https://issues.apache.org/jira/browse/SPARK-59827)). The allocator retries that
+([SPARK-59444](https://issues.apache.org/jira/browse/SPARK-59444)). The allocator retries that
 case, since the failed call was granted nothing, and after three attempts throws
 `SparkOutOfMemoryError`, which the shuffle writers handle like any other refused page. Only the
 shuffle allocator's callers are guarded this way. Spark's operators in the same task, such as its
 sorters and aggregates, can still hit the exception until Spark re-registers a waiting task in
-`ExecutionMemoryPool` ([apache/spark#59103](https://github.com/apache/spark/pull/59103)).
+`ExecutionMemoryPool` ([apache/spark#58747](https://github.com/apache/spark/pull/58747)).
 
 Which allocator each call site uses, and who ends up charged for the bytes:
 
 
@@ -91,7 +91,7 @@ public LongArray allocateArray(long size) {
    * drops the entry at a zero balance, so trying again is safe: it registers the task again and
    * waits for its share as Spark would have. After a few failed attempts the allocation fails with
    * a SparkOutOfMemoryError, which the shuffle writers handle like any other refused page, caused
-   * by the last attempt's exception. The Spark issue is SPARK-59827.
+   * by the last attempt's exception. The Spark issue is SPARK-59444.
    */
   private <T> T retryMissingTaskEntry(long required, Supplier<T> allocation) {
     for (int attempt = 1; ; attempt++) {