av9ash/GitBugs huggingface dataset:
Bug: Extract pushable predicates from disjunctive predicates
Status: Open | Priority: Major | Resolution: 
Created: 20/Jul/23 07:35
Affects Version/s: 4.0.0

Example:
{code:sql}
select count(*)
from
  db.very_large_table
where
  session_start_dt between date_sub('2023-07-15', 1) and date_add('2023-07-16', 1)
  and type = 'event'
  and date(event_timestamp) between '2023-07-15' and '2023-07-16'
  and (
    (
      page_id in (2627, 2835, 2402999)
      and -- other predicates
      and rdt = 0
    ) or (
      page_id in (2616, 3411350)
      and rdt = 0
    ) or (
      page_id = 2403006
    ) or (
      page_id in (2208336, 2356359)
      and -- other predicates
      and rdt = 0
    )
  )
{code}

We can push down {{page_id in(2627, 2835, 2402999, 2616, 3411350, 2403006, 2208336, 2356359)}} to datasource.
Before:
 !before.png! 
After:
 !after.png!
Bug: Use `org.seleniumhq.selenium.htmlunit3-driver` instead of `net.sourceforge.htmlunit`
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Jul/23 18:29
Affects Version/s: 3.5.0

[CVE-2023-26119|https://nvd.nist.gov/vuln/detail/CVE-2023-26119]
Bug: Scala None shows up as null for Aggregator BUF or OUT  
Status: Open | Priority: Major | Resolution: 
Created: 06/Jul/23 17:08
Affects Version/s: 3.4.1

when doing an upgrade from spark 3.3.1 to spark 3.4.1 we suddenly started getting null pointer exceptions in Aggregators (classes extending org.apache.spark.sql.expressions.Aggregator) that use scala Option for BUF and/or OUT. basically None is now showing up as null.

after adding a simple test case and doing a binary search on commits we landed on SPARK-37829 being the cause.

we observed the issue at first with NPE inside Aggregator.merge because None was null. i am having a hard time replicating that in a spark unit test, but i did manage to get a None become null in the output. simple test that now fails:

 
{code:java}
diff --git a/sql/core/src/test/scala/org/apache/spark/sql/DatasetAggregatorSuite.scala b/sql/core/src/test/scala/org/apache/spark/sql/DatasetAggregatorSuite.scala
index e9daa825dd4..a1959d7065d 100644
--- a/sql/core/src/test/scala/org/apache/spark/sql/DatasetAggregatorSuite.scala
+++ b/sql/core/src/test/scala/org/apache/spark/sql/DatasetAggregatorSuite.scala
@@ -228,6 +228,16 @@ case class FooAgg(s: Int) extends Aggregator[Row, Int, Int] {
   def outputEncoder: Encoder[Int] = Encoders.scalaInt
 }
 
+object OptionStringAgg extends Aggregator[Option[String], Option[String], Option[String]] {
+  override def zero: Option[String] = None
+  override def reduce(b: Option[String], a: Option[String]): Option[String] = merge(b, a)
+  override def finish(reduction: Option[String]): Option[String] = reduction
+  override def merge(b1: Option[String], b2: Option[String]): Option[String] =
+    b1.map{ b1v => b2.map{ b2v => b1v ++ b2v }.getOrElse(b1v) }.orElse(b2)
+  override def bufferEncoder: Encoder[Option[String]] = ExpressionEncoder()
+  override def outputEncoder: Encoder[Option[String]] = ExpressionEncoder()
+}
+
 class DatasetAggregatorSuite extends QueryTest with SharedSparkSession {
   import testImplicits._
 
@@ -432,4 +442,15 @@ class DatasetAggregatorSuite extends QueryTest with SharedSparkSession {
     val agg = df.select(mode(col("a"))).as[String]
     checkDataset(agg, "3")
   }
+
+  test("typed aggregation: option string") {
+    val ds = Seq((1, Some("a")), (1, None), (1, Some("c")), (2, None)).toDS()
+
+    checkDataset(
+      ds.groupByKey(_._1).mapValues(_._2).agg(
+        OptionStringAgg.toColumn
+      ),
+      (1, Some("ac")), (2, None)
+    )
+  }
 }
 {code}
Bug: Add support for MSK IAM to the kafka connector
Status: Open | Priority: Major | Resolution: 
Created: 03/Jul/23 23:18
Affects Version/s: 3.4.1

Managed Streaming for Kafka (MSK) is a fully managed service offered by Amazon Web Services (AWS) that simplifies the deployment, management, and scaling of Apache Kafka clusters. Kafka is an open-source streaming platform widely used for building real-time data pipelines and streaming applications. MSK provides a managed environment for running Kafka clusters, reducing the operational overhead associated with self-managing Kafka infrastructure.

Currently when we connect to MSK using spark, users would have to install an external library and then try to connect with MSK IAM auth. To simplify this for users, we can add this as a dependency directly to Spark and then users can connect to it by simply specifying the class paths directly.
Bug: Wrong results for dense_rank() <= k from InferWindowGroupLimit and DenseRankLimitIterator
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Jul/23 22:46
Affects Version/s: 3.5.0

Top-k filters on a dense_rank() window function return wrong results, due to a bug in optimization InferWindowGroupLimit, specifically in the code for DenseRankLimitIterator, introduced in https://issues.apache.org/jira/browse/SPARK-37099.

Repro:
{code:java}
create or replace temp view t1 (p, o) as values (1, 1), (1, 1), (1, 2), (2, 1), (2, 1), (2, 2);

select * from (select *, dense_rank() over (partition by p order by o) as rnk from t1) where rnk = 1;{code}
Spark result:
{code:java}
[1,1,1]
[1,1,1]
[2,1,1]{code}
Correct result:
{code:java}
[1,1,1]
[1,1,1]
[2,1,1]
[2,1,1]{code}
 

The bug is in {{{}DenseRankLimitIterator{}}}, it fails to reset state properly when transitioning from one window partition to the next. {{reset}} only resets {{{}rank = 0{}}}, what it is missing is to reset {{{}currentRankRow = null{}}}. This means that when processing the second and later window partitions, the rank incorrectly gets incremented based on comparing the ordering of the last row of the previous partition to the first row of the new partition.

This means that a dense_rank window func that has more than one window partition and more than one row with dense_rank = 1 in the second or later partitions can give wrong results when optimized.

({{{}RankLimitIterator{}}} narrowly avoids this bug by happenstance, the first row in the new partition will try to increment rank, but increment it by the value of count which is 0, so it happens to work by accident).

Unfortunately, tests for the optimization only had a single row per rank, so did not catch the bug as the bug requires multiple rows per rank.
Bug: Reuse spark build among pyspark-* modules
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 27/Jul/23 11:07
Affects Version/s: 4.0.0

In every `PySpark-*` test modules, it needs to build the spark with sbt/maven and normally takes 20~30 minutes.

Maybe we could build it once, and then use it in all related test modules.
Bug: Use PartitionEvaluator API in ArrowEvalPythonUDTFExec & BatchEvalPythonUDTFExec
Status: Open | Priority: Major | Resolution: 
Created: 13/Jul/23 21:52
Affects Version/s: 3.5.0

Use PartitionEvaluator API in

`ArrowEvalPythonUDTFExec`

`BatchEvalPythonUDTFExec`
Bug: Use PartitionEvaluator API in FileSourceScanExec, RowDataSourceScanExec, MergeRowsExec
Status: Open | Priority: Major | Resolution: 
Created: 10/Jul/23 20:28
Affects Version/s: 3.5.0

Define the computing logic through PartitionEvaluator API and use it in SQL operators 

FileSourceScanExec

RowDataSourceScanExec

MergeRowsExec
Bug: first operator should respect the nullability of child expression as well as ignoreNulls option
Status: Open | Priority: Major | Resolution: 
Created: 24/Jul/23 02:14
Affects Version/s: 3.2.0

I found the following problem when using Spark recently:

 
{code:java}
// code placeholder
import spark.implicits._

val s = Seq((1.2, "s", 2.2)).toDF("v1", "v2", "v3")

val schema = StructType(Seq(StructField("v1", DoubleType, nullable = false),StructField("v2", StringType, nullable = true),StructField("v3", DoubleType, nullable = false)))

val df = spark.createDataFrame(s.rdd, schema)val inputDF = 

val inputDF = df.dropDuplicates("v3")

spark.sql("CREATE TABLE local.db.table (\n v1 DOUBLE NOT NULL,\n v2 STRING, v3 DOUBLE NOT NULL)")

inputDF.write.mode("overwrite").format("iceberg").save("local.db.table") {code}
 

 

when I use the above code to write to iceberg (i guess Delta Lake will have the same problem) , I got very confusing exception


{code:java}
Exception in thread "main" java.lang.IllegalArgumentException: Cannot write incompatible dataset to table with schema:

table 

{  1: v1: required double  2: v2: optional string  3: v3: required double}

Provided schema:

table {  1: v1: optional double  2: v2: optional string  3: v3: required double} {code}

basically it complains that we have v1 as the nullable column in our `inputDF` above which is not allowed since we created table with the v1 as not nullable. The confusion comes from that,  if we check the schema with printSchema() of inputDF, v1 is not nullable
{noformat}
root 
|-- v1: double (nullable = false) 
|-- v2: string (nullable = true) 
|-- v3: double (nullable = false){noformat}
Clearly, something changed the v1's nullability unexpectedly!

 

After some debugging I found that the key is that dropDuplicates("v3"). In optimization phase, we have ReplaceDeduplicateWithAggregate to replace the Deduplicate with aggregate on v3 and run first() over all other columns. However, first() operator has hard coded nullable as always "true" which is the source of changed nullability of v1

 

this is a very confusing behavior of Spark, and probably no one really noticed as we do not care too much without the new table formats like delta lake and iceberg which can make nullability check correctly. Nowadays, we users adopt them more and more, this is surfaced up
Bug: Support to extract partial filters of datasource v2 table and push them down
Status: Open | Priority: Major | Resolution: 
Created: 14/Jul/23 05:57
Affects Version/s: 3.1.2

 

Run the following sql, and the date predicate in the where clause is not pushed down and it would cause a full table scan.

 
{code:java}
SELECT
id,
data,
date
FROM
testcat.db.table
where
(date = 20221110 and udfStrLen(data) = 8)
or
(date = 20221111 and udfStrLen(data) = 8)  {code}
Bug: optimize adaptive skew join for ExistenceJoin
Status: Open | Priority: Major | Resolution: 
Created: 14/Jul/23 10:24
Affects Version/s: 3.1.2

For this query,  InSubQuery would be cast to ExistenceJoin and now ExistenceJoin does not support automatic data skew for the left table.
{code:java}
SELECT * FROM skewData1
where
(key1 in (select key2 from skewData2)
or value1 in (select value2 from skewData2){code}
Bug: change the external catalog thread safety way
Status: Open | Priority: Major | Resolution: 
Created: 18/Jul/23 07:38
Affects Version/s: 3.4.1

We test changing the sync of the external catalog to use thread-local instead of the synchronized methods.

in our tests, it improve the runtime of parallel actions by about 45% for certain workload ** (time reduced from ~15min to ~9min)
Bug: Use PartitionEvaluator API in HashAggregateExec, ObjectHashAggregateExec, SortAggregateExec
Status: Open | Priority: Major | Resolution: 
Created: 12/Jul/23 12:26
Affects Version/s: 3.5.0

Use PartitionEvaluator API in HashAggregateExec, ObjectHashAggregateExec, SortAggregateExec
Bug: Fixed matching check for CharType/VarcharType
Status: Open | Priority: Major | Resolution: 
Created: 14/Jul/23 02:22
Affects Version/s: 3.1.2

Running the following code throws an exception
{code:java}
val analyzer = getAnalyzer
// check varchar type
val json1 = "{\"__CHAR_VARCHAR_TYPE_STRING\":\"varchar(80)\"}"
val metadata1 = new MetadataBuilder().withMetadata(Metadata.fromJson(json1)).build()

val query1 = TestRelation(StructType(Seq(
StructField("x", StringType, metadata = metadata1),
StructField("y", StringType, metadata = metadata1))).toAttributes)

val table1 = TestRelation(StructType(Seq(
StructField("x", StringType, metadata = metadata1),
StructField("y", StringType, metadata = metadata1))).toAttributes)

val parsedPlanByName1 = byName(table1, query1)
analyzer.executeAndCheck(parsedPlanByName1, new QueryPlanningTracker()) {code}
 

Exception details are as follows
{code:java}
org.apache.spark.sql.AnalysisException: unresolved operator 'AppendData TestRelation [x#8, y#9], true;
'AppendData TestRelation [x#8, y#9], true
+- TestRelation [x#6, y#7]    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis.failAnalysis(CheckAnalysis.scala:52)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis.failAnalysis$(CheckAnalysis.scala:51)
    at org.apache.spark.sql.catalyst.analysis.Analyzer.failAnalysis(Analyzer.scala:156)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis.$anonfun$checkAnalysis$47(CheckAnalysis.scala:704)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis.$anonfun$checkAnalysis$47$adapted(CheckAnalysis.scala:702)
    at org.apache.spark.sql.catalyst.trees.TreeNode.foreachUp(TreeNode.scala:186)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis.checkAnalysis(CheckAnalysis.scala:702)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis.checkAnalysis$(CheckAnalysis.scala:92)
    at org.apache.spark.sql.catalyst.analysis.Analyzer.checkAnalysis(Analyzer.scala:156)
    at org.apache.spark.sql.catalyst.analysis.Analyzer.$anonfun$executeAndCheck$1(Analyzer.scala:177)
    at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper$.markInAnalyzer(AnalysisHelper.scala:228)
    at org.apache.spark.sql.catalyst.analysis.Analyzer.executeAndCheck(Analyzer.scala:174)
    at org.apache.spark.sql.catalyst.analysis.DataSourceV2AnalysisBaseSuite.$anonfun$new$36(DataSourceV2AnalysisSuite.scala:691) {code}
Bug: Use PartitionEvaluator API in FlatMapGroupsInPandasExec, FlatMapCoGroupsInPandasExec
Status: Open | Priority: Major | Resolution: 
Created: 16/Jul/23 21:42
Affects Version/s: 3.5.0

Use PartitionEvaluator API in

`FlatMapGroupsInPandasExec`

`FlatMapCoGroupsInPandasExec`
Bug: Use  PartitionEvaluator API in AggregateInPandasExec, AttachDistributedSequenceExec
Status: Open | Priority: Major | Resolution: 
Created: 10/Jul/23 19:32
Affects Version/s: 3.5.0

Use  PartitionEvaluator API in

`AggregateInPandasExec`

`AttachDistributedSequenceExec`
Bug: Use PartitionEvaluator API in CoGroupExec, DeserializeToObjectExec, ExternalRDDScanExec
Status: Open | Priority: Major | Resolution: 
Created: 15/Jul/23 08:11
Affects Version/s: 3.5.0

Use PartitionEvaluator API in CoGroupExec, DeserializeToObjectExec, ExternalRDDScanExec
Bug: DataFrame depending on temp view fail after the view is dropped
Status: Open | Priority: Major | Resolution: 
Created: 13/Jul/23 04:02
Affects Version/s: 3.5.0

In vanilla Spark:


{code:java}
In [1]: df = spark.createDataFrame([(1, 4), (2, 4), (3, 6)], ["A", "B"])

In [2]: df.createOrReplaceTempView("t")

In [3]: df2 = spark.sql("select * from t")

In [4]: df2.show()
+---+---+                                                                       
|  A|  B|
+---+---+
|  1|  4|
|  2|  4|
|  3|  6|
+---+---+


In [5]: spark.catalog.dropTempView("t")
Out[5]: True

In [6]: df2.show()
+---+---+
|  A|  B|
+---+---+
|  1|  4|
|  2|  4|
|  3|  6|
+---+---+
{code}


In Spark Connect:


{code:java}
In [1]: df = spark.createDataFrame([(1, 4), (2, 4), (3, 6)], ["A", "B"])

In [2]: df.createOrReplaceTempView("t")

In [3]: df2 = spark.sql("select * from t")

In [4]: df2.show()
+---+---+
|  A|  B|
+---+---+
|  1|  4|
|  2|  4|
|  3|  6|
+---+---+


In [5]: spark.catalog.dropTempView("t")
Out[5]: True

In [6]: df2.show()
23/07/13 11:57:18 ERROR SparkConnectService: Error during: execute. UserId: ruifeng.zheng. SessionId: 1fc234fd-07da-4ad0-9ec5-2d818cef6033.
org.apache.spark.sql.AnalysisException: [TABLE_OR_VIEW_NOT_FOUND] The table or view `t` cannot be found. Verify the spelling and correctness of the schema and catalog.
If you did not qualify the name with a schema, verify the current_schema() output, or qualify the name with the correct schema and catalog.
To tolerate the error on drop use DROP VIEW IF EXISTS or DROP TABLE IF EXISTS.; line 1 pos 14;
'Project [*]
+- 'UnresolvedRelation [t], [], false


{code}
Bug: Porting k8s PVC reuse logic to spark standalone
Status: Open | Priority: Major | Resolution: 
Created: 24/Jul/23 14:06
Affects Version/s: 3.4.1

Hi,

This ticket is meant to understand the work that would be involved in porting the k8s PVC reuse feature onto the spark standalone cluster manager which reuses the shuffle files present locally in the disk

We are a heavy user of spot instances and we suffer from spot terminations impacting our long running jobs

The logic in `KubernetesLocalDiskShuffleExecutorComponents` itself is not that much. However when I tried this on the `LocalDiskShuffleExecutorComponents` it was not a successful experiment which suggests there is more to recovering shuffle files

I'd like to understand what will be the work involved for this. We'll be more than happy to contribute
Bug: Define the computing logic through PartitionEvaluator API and use it in BroadcastNestedLoopJoinExec & BroadcastHashJoinExec
Status: Open | Priority: Major | Resolution: 
Created: 07/Jul/23 03:44
Affects Version/s: 3.5.0

Define the computing logic through PartitionEvaluator API and use it in BroadcastNestedLoopJoinExec & BroadcastHashJoinExec
Bug: Wrong semantics for null IN (empty list)
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 26/Jul/23 03:26
Affects Version/s: 3.4.0

{{null IN (empty list)}} incorrectly evaluates to null, when it should evaluate to false. (The reason it should be false is because a IN (b1, b2) is defined as a = b1 OR a = b2, and an empty IN list is treated as an empty OR which is false. This is specified by ANSI SQL.)

Many places in Spark execution (In, InSet, InSubquery) and optimization (OptimizeIn, NullPropagation) implemented this wrong behavior. Also note that the Spark behavior for the null IN (empty list) is inconsistent in some places - literal IN lists generally return null (incorrect), while IN/NOT IN subqueries mostly return false/true, respectively (correct) in this case.

This is a longstanding correctness issue which has existed since null support for IN expressions was first added to Spark.

Doc with more details: [https://docs.google.com/document/d/1k8AY8oyT-GI04SnP7eXttPDnDj-Ek-c3luF2zL6DPNU/edit]
Bug: Enable KernelDensity within Spark Connect
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Jul/23 07:39
Affects Version/s: 3.5.0

import pyspark.pandas as ps
psdf = ps.DataFrame(\{"a": [1, 2, 3, 4, 5], "b": [1, 3, 5, 7, 9], "c": [2, 4, 6, 8, 10]})
psdf.plot.kde(bw_method=5, ind=3)
Bug: Support Interrupt On Cancel in SQLExecution
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 28/Jul/23 03:50
Affects Version/s: 3.5.0

Currently, we support interrupting task threads for users by 1) APIs of the spark core module, 2) a thrift config for the SQL module.  Other Spark SQL Apps are limited to use this functionality. Specifically,  the built-in spark-sql-shell lacks a user-controlled knob for interrupting task threads.
Bug: Group FileStatus with few RPC calls within Yarn Client
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 05/Jul/23 03:59
Affects Version/s: 0.9.2

It's inefficient to obtain *FileStatus* for each resource [one by one|https://github.com/apache/spark/blob/531ec8bddc8dd22ca39486dbdd31e62e989ddc15/resource-managers/yarn/src/main/scala/org/apache/spark/deploy/yarn/ClientDistributedCacheManager.scala#L71C1]. In our company setting, we are running Spark with Hadoop Yarn and HDFS. We noticed the current behavior has two major drawbacks:
 # Since each *getFileStatus* call involves network delays, the overall delay can be *large* and add *uncertainty* to the overall Spark job runtime. Specifically, we quantify this overhead within our cluster. We see the p50 overhead is around 10s, p80 is 1 min, and p100 is up to 15 mins. When HDFS is overloaded, the delays become more severe. 
 # In our cluster, we have nearly 100 million *getFileStatus* call to HDFS daily. We noticed that in our cluster, most resources come from the same HDFS directory for each user (See our [engineer blog post|https://engineering.linkedin.com/blog/2023/reducing-apache-spark-application-dependencies-upload-by-99-] about why we took this approach). Therefore, we can greatly reduce nearly 100 million *getFileStatus* call to 0.1 million *listStatus* calls daily. This will further reduce overhead from the HDFS side. 

All in all, a more efficient way to fetch the *FileStatus* for each resource is highly needed.
Bug: RocksDB crashed when testing in GitHub Actions
Status: Open | Priority: Major | Resolution: 
Created: 28/Jul/23 05:30
Affects Version/s: 3.5.0

[https://github.com/LuciferYang/spark/actions/runs/5666554831/job/15395578871]

 
{code:java}
#
17177# A fatal error has been detected by the Java Runtime Environment:
17178#
17179#  SIGSEGV (0xb) at pc=0x00007f8a077d2743, pid=4403, tid=0x00007f89cadff640
17180#
17181# JRE version: OpenJDK Runtime Environment (8.0_372-b07) (build 1.8.0_372-b07)
17182# Java VM: OpenJDK 64-Bit Server VM (25.372-b07 mixed mode linux-amd64 compressed oops)
17183# Problematic frame:
17184# C  [librocksdbjni886380103972770161.so+0x3d2743]  rocksdb::DBImpl::FailIfCfHasTs(rocksdb::ColumnFamilyHandle const*) const+0x23
17185#
17186# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
17187#
17188# An error report file with more information is saved as:
17189# /home/runner/work/spark/spark/sql/core/hs_err_pid4403.log
17190#
17191# If you would like to submit a bug report, please visit:
17192#   https://github.com/adoptium/adoptium-support/issues
17193# The crash happened outside the Java Virtual Machine in native code.
17194# See problematic frame for where to report the bug.
17195# {code}
 

This is my first time encountering this problem, and I am  unsure of the root cause now
Bug: Implement termination of Python process for foreachBatch & streaming listener
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/Jul/23 17:55
Affects Version/s: 3.4.1

In the first implementation of Python support for foreachBatch, the python process termination is not handled correctly. 

 

See the long TODO in [https://github.com/apache/spark/blob/master/connector/connect/server/src/main/scala/org/apache/spark/sql/connect/planner/StreamingForeachBatchHelper.scala] 

about an outline of the feature to terminate the runners by registering StreamingQueryListners.
Bug: Refine the documents with LLM
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 27/Jul/23 04:45
Affects Version/s: 4.0.0

Let's first focus on the Documents of *PySpark DataFrame APIs*.

*1*, Chose a subset of DF APIs
Since the review bandwidth is limited, we recommend each PR contains at least 5 APIs;

*2*, For each API, copy-paste the function (including function signature, doc string) to a LLM Model, and ask it to with a prompts (e.g. the attached prompt), you can of course use/design your own prompt.
For prompt engineering, you can refer to this [Best practices|https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-openai-api] 

*3*, Note that the LLM is not 100% reliable, the generated doc string may still contain some mistakes, e.g.
* The example code can not run
* The example results are incorrect
* The example code doesn't reflect the example title
* The description use wrong version, add a 'Raise' selection for non-existent exception
* The lint can be broken
* ...

we need to fix them before sending a PR.

We can try different prompts, choose the good parts and combine them to the new doc sting.