av9ash/GitBugs huggingface dataset:
Bug: SHOW CREATE TABLE does not quote identifiers with special characters
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/Jul/23 06:32
Affects Version/s: 3.4.0

Create a table with special characters:

```

CREATE CATALOG `a_catalog-with+special^chars`; CREATE SCHEMA `a_catalog-with+special^chars`.`a_schema-with+special^chars`; CREATE TABLE `a_catalog-with+special^chars`.`a_schema-with+special^chars`.`table1` ( id int, feat1 varchar(255), CONSTRAINT pk PRIMARY KEY (id,feat1) );

```

Then run SHOW CREATE TABLE:

```

SHOW CREATE TABLE `a_catalog-with+special^chars`.`a_schema-with+special^chars`.`table1`;

```

The response is:

```

createtab_stmt "CREATE TABLE a_catalog-with+special^chars.a_schema-with+special^chars.table1 ( id INT NOT NULL, feat1 VARCHAR(255) NOT NULL, CONSTRAINT pk PRIMARY KEY (id, feat1)) USING delta TBLPROPERTIES ( 'delta.minReaderVersion' = '1', 'delta.minWriterVersion' = '2') "

```

As you can see, the table name in the response is not properly escaped with backticks. As a result, if a user copies and pastes this create table command to recreate the table, it will fail:

{{[INVALID_IDENTIFIER] The identifier a_catalog-with is invalid. Please, consider quoting it with back-quotes as `a_catalog-with`.(line 1, pos 22)}}
Bug: Replace the term UNSUPPORTED_DATA_SOURCE_FOR_DIRECT_QUERY with UNSUPPORTED_DATASOURCE_FOR_DIRECT_QUERY
Status: Open | Priority: Major | Resolution: 
Created: 24/Jul/23 05:58
Affects Version/s: 3.5.0

Remove term UNSUPPORTED_DATA_SOURCE_FOR_DIRECT_QUERY in favor of UNSUPPORTED_DATASOURCE_FOR_DIRECT_QUERY
Bug: optimize generateTreeString code path
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Jul/23 21:25
Affects Version/s: 3.4.1

In `TreeNode.generateTreeString`, we observed inefficiency in scala collection operations and virtual function call.

This inefficiency become significant in large plan (we hit a example of more than 1000 nodes). So {*}it’s worth optimizing the super hot code path{*}. By rewriting into native Java code(not so sweet as scala syntax sugar though), we should be able to get rid of most of the overhead.
Bug: Define the computing logic through PartitionEvaluator API and use it in BaseScriptTransformationExec, InMemoryTableScanExec, ReferenceSort, HiveTableScanExec, SortExec
Status: Open | Priority: Major | Resolution: 
Created: 10/Jul/23 18:45
Affects Version/s: 3.5.0

Define the computing logic through PartitionEvaluator API and use it in SQL aggregate operators

BaseScriptTransformationExec

InMemoryTableScanExec

ReferenceSort

HiveTableScanExec

SortExec
Bug: Fix applyInPandasWithStatePythonRunner to output rows that have Null as first column value
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/Jul/23 20:00
Affects Version/s: 3.3.3

The current implementation of {{ApplyInPandasWithStatePythonRunner}} cannot deal with outputs where the first column of the row is {{{}null{}}}, as it cannot distinguish the case where the column is null, or the field is filled as the number of data records are smaller than state records. It causes incorrect results for the former case.
Bug: KubernetesSuite report NPE when not set spark.kubernetes.test.unpackSparkDir
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Jul/23 01:56
Affects Version/s: 3.4.1

KubernetesSuite report NPE when not set spark.kubernetes.test.unpackSparkDir

 

Exception encountered when invoking run on a nested suite.
java.lang.NullPointerException
    at sun.nio.fs.UnixPath.normalizeAndCheck(UnixPath.java:77)
    at sun.nio.fs.UnixPath.<init>(UnixPath.java:71)
    at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
    at java.nio.file.Paths.get(Paths.java:84)
    at org.apache.spark.deploy.k8s.integrationtest.KubernetesSuite.$anonfun$beforeAll$4(KubernetesSuite.scala:164)
    at org.apache.spark.deploy.k8s.integrationtest.KubernetesSuite.$anonfun$beforeAll$4$adapted(KubernetesSuite.scala:163)
    at scala.collection.LinearSeqOptimized.find(LinearSeqOptimized.scala:115)
    at scala.collection.LinearSeqOptimized.find$(LinearSeqOptimized.scala:112)
    at scala.collection.immutable.List.find(List.scala:91)
    at org.apache.spark.deploy.k8s.integrationtest.KubernetesSuite.beforeAll(KubernetesSuite.scala:163)
Bug: FileSourceScanExec OutputPartitioning for non bucketed scan
Status: Open | Priority: Major | Resolution: 
Created: 20/Jul/23 13:42
Affects Version/s: 3.4.1

FileSourceScanExec.outputPartitioning currently is calculated for bucketed scan only and for non-bucketed scan, we return UnknownPartitioning(0). This may result into unnecessary empty tasks creation, based on the SQLConf defaultParallelism setting even though the actual file may have very low number of partitions.

We need to also calculate and set the number of output partitions correctly for non-bucketed scan.
Bug: Add support for Micrometer Observation
Status: Open | Priority: Major | Resolution: 
Created: 20/Jul/23 10:56
Affects Version/s: 3.5.0

I'm a co-maintainer of Spring Cloud Sleuth and Micrometer projects (together with Tommy Ludwig and Jonatan Ivanov).

[Micrometer Observation|https://micrometer.io/docs/observation] is part of the Micrometer 1.10 release and [Micrometer Tracing|https://micrometer.io/docs/tracing] is a new project. The idea of Micrometer Observation is that you instrument code once but you get multiple benefits out of it - e.g. you can get tracing, metrics, logging or whatever you see fit).

I was curious if there's interest in adding Micrometer Observation support so that automatically (when on classpath) except for metrics, spans could be created and tracing context propagation could happen too. In other words metrics and tracing of this project could be created + if there are Micrometer Observation compatible projects, then they will join the whole graph (e.g. whole Spring Framework 6 is, Apache Dubbo, Apache Camel, Resilience4j etc.)

If there's interest in adding that feature, I can provide a PR.
Bug: Make pyspark.sql.is_remote an API
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Jul/23 10:20
Affects Version/s: 4.0.0

We should make \{{pyspark.sql.utils.is_remote}} an API so the end users can do if-else, e.g., for dispatching the code path to the legacy mode or connect mode.
Bug: Use PartitionEvaluator API in ArrowEvalPythonExec, BatchEvalPythonExec
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Jul/23 20:17
Affects Version/s: 3.5.0

Use PartitionEvaluator API in

`ArrowEvalPythonExec`

`BatchEvalPythonExec`
Bug: JobArtifactSet is populated with all artifacts if it is not associated with an artifact
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 18/Jul/23 14:34
Affects Version/s: 3.5.0

Consider each artifact type - files/jars/archives. For each artifact type, the following bug exists:
 # Initialise a `JobArtifactState` with no artifacts added to it.
 # Create a  `JobArtifactSet` from the `JobArtifactState`.
 # Add an artifact with the same active `JobArtifactState`.
 # Create another `JobArtifactSet`

In the current behaviour, the set created in step 2 contains all the artifacts (through `sc.allAddedFiles` for example) while step 3 contains only the single artifact added in step 3.
Bug: ThreadLocal not being copied to child thread when child thread is reused from pool 
Status: Open | Priority: Major | Resolution: 
Created: 17/Jul/23 11:26
Affects Version/s: 3.1.0

Currently setting the Spark configuration using the statement `spark.conf.set("spark.sql.caseSensitive", "true")` and subsequently executing a Spark action in a separate thread. An intermittent observation reveals that occasionally the configuration set in the main thread fails to propagate to the child thread

Steps to repro: [Spark SQL configs can't get propagated properly to a new thread in Spark 3.1 issue · GitHub|https://gist.github.com/t-rufang/25341b3678e5d7c74e3a209457fce0e9]

 

This is limitation due to ThreadLocal not being copied to child thread when child thread is reused from pool and only done instead in thread creation or when idle thread has expired KeepAlive in Executor

Refer:  

[https://users.scala-lang.org/t/future-executioncontext-and-threadlocal/7675/2] 

[https://www.stevenskelton.ca/threadlocal-variables-scala-futures/]
Bug: Use difflib to display errors in assertDataFrameEqual
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/Jul/23 03:38
Affects Version/s: 3.5.0

SPIP: https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
Bug: Add checks for expected list type special cases
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Jul/23 19:42
Affects Version/s: 3.5.0

SPIP: https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
Bug: Make MsSqlServerIntegrationSuite robust in ANSI mode
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/Jul/23 15:32
Affects Version/s: 3.5.0

{noformat}
2023-07-14T15:14:16.0646055Z [0m[[0m[0minfo[0m] [0m[0m[31m- SPARK-38889: MsSqlServerDialect should handle boolean filter push down *** FAILED *** (133 milliseconds)[0m[0m
2023-07-14T15:14:16.0648223Z [0m[[0m[0minfo[0m] [0m[0m[31m  org.apache.spark.sql.AnalysisException: [DATATYPE_MISMATCH.BINARY_OP_DIFF_TYPES] Cannot resolve "(c = 0)" due to data type mismatch: the left and right operands of the binary operator have incompatible types ("BOOLEAN" and "INT").;[0m[0m
{noformat}
Bug: Shutdown maintenance task thread on error
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/Jul/23 19:55
Affects Version/s: 3.5.0

Shutdown maintenance task thread on error

 

Currently if we get an error on maintenance, the future is set to false, but the thread is actually never reaped. If this happens often, we end up accumulating the state store threads that don't have any reference. Eventually this could lead to thread exhaustion.

 

Eg logs -
{code:java}
log4j-2023-07-13-18.log:6968:23/07/13 18:34:25 INFO StateStore: State Store maintenance task started
log4j-2023-07-13-18.log:282671:23/07/13 18:43:28 INFO StateStore: State Store maintenance task started
log4j-2023-07-13-18.log:322145:23/07/13 18:44:32 INFO StateStore: State Store maintenance task started
log4j-2023-07-13-18.log:361192:23/07/13 18:45:37 INFO StateStore: State Store maintenance task started
log4j-2023-07-13-18.log:398145:23/07/13 18:46:37 INFO StateStore: State Store maintenance task started
log4j-2023-07-13-18.log:436591:23/07/13 18:47:42 INFO StateStore: State Store maintenance task started
log4j-2023-07-13-18.log:478531:23/07/13 18:48:47 INFO StateStore: State Store maintenance task started {code}
Bug: ALTER COLUMN to increase VARCHAR size fails
Status: Open | Priority: Major | Resolution: 
Created: 14/Jul/23 18:35
Affects Version/s: 3.3.2

I tried to expand a VARCHAR column by running the following commands but ran into an error when doing so.

 
{code:java}
spark.sql("DROP TABLE IF EXISTS default.test_table")

spark.sql("CREATE TABLE default.test_table (test_col VARCHAR(10))")

spark.sql("ALTER TABLE default.test_table ALTER COLUMN test_col TYPE VARCHAR(25)") {code}
 

The error I get:

pyspark.sql.utils.AnalysisException: ALTER TABLE CHANGE COLUMN is not supported for changing column 'test_col' with type 'VarcharType(10)' to 'test_col' with type 'VarcharType(25)'
Bug: `url_decode` can fail w/ an internal error
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jul/23 15:54
Affects Version/s: 3.5.0

The function *url_decode* can fail with the error:


{code:java}
org.apache.spark.SparkException: [INTERNAL_ERROR] The Spark SQL phase analysis failed with an internal error. You hit a bug in Spark or the Spark plugins you use. Please, report this bug to the corresponding communities or vendors, and provide the full stack trace. 
at org.apache.spark.SparkException$.internalError(SparkException.scala:89) 
at org.apache.spark.sql.execution.QueryExecution$.toInternalError(QueryExecution.scala:871) 
...
Caused by: java.lang.AssertionError: assertion failed: Incorrect number of children
        at scala.Predef$.assert(Predef.scala:223)
        at org.apache.spark.sql.catalyst.trees.TreeNode.withNewChildren(TreeNode.scala:391)
        at org.apache.spark.sql.catalyst.analysis.TypeCoercionBase$ImplicitTypeCasts$$anonfun$11.applyOrElse(TypeCoercion.scala:707)
{code}
Bug: Support List[Row] data type for expected DataFrame argument
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Jul/23 19:44
Affects Version/s: 3.5.0

SPIP: https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
Bug: Using an updated instance of ScalarUserDefinedFunction causes protobuf cast failures on server
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jul/23 15:13
Affects Version/s: 3.5.0

When running the following code-
{code:java}
class A(x: Int) { def get = x * 7 }
val myUdf = udf((x: Int) => new A(x).get)
val modifiedUdf = myUdf.withName("myUdf")
spark.range(5).select(modifiedUdf(col("id"))).as[Int].collect(){code}
which modifies the original myUdf instance through the `withName` method causes the following error to occur during execution:
{noformat}
java.lang.ClassCastException: org.apache.spark.connect.proto.ScalarScalaUDF cannot be cast to com.google.protobuf.MessageLite
    at com.google.protobuf.GeneratedMessageLite$SerializedForm.readResolve(GeneratedMessageLite.java:1462)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1274)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2405)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2285)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2187)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2405)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2329)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2187)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
    at java.io.ObjectInputStream.readArray(ObjectInputStream.java:2093)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1655)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2405)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2329)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2187)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2405)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2329)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2187)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
    at org.apache.spark.util.Utils$.deserialize(Utils.scala:148){noformat}
Bug: Expose assertDataFrameEqual in pyspark.testing.utils
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jul/23 19:30
Affects Version/s: 3.5.0

SPIP: https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
Bug: Jobs that have join & have .rdd calls get executed 2x when AQE is enabled.
Status: Open | Priority: Major | Resolution: 
Created: 11/Jul/23 16:35
Affects Version/s: 3.1.2

We have a few spark scala jobs that are currently running in production. Most jobs typically use Dataset, Dataframes. There is a small code in our custom library code, that makes rdd calls example to check if the dataframe is empty: df.rdd.getNumPartitions == 0

When I enable aqe for these jobs, this .rdd is converted into a separate job of it's own and the entire dag is executed 2x, taking 2x more time. This does not happen when AQE is disabled. Why does this happen and what is the best way to fix the issue?

 

Sample code to reproduce the issue:

 

 
{code:java}
import org.apache.spark.sql._ 
  case class Record(
    id: Int,
    name: String
 )
 
    val partCount = 4
    val input1 = (0 until 100).map(part => Record(part, "a"))
 
    val input2 = (100 until 110).map(part => Record(part, "c"))
 
    implicit val enc: Encoder[Record] = Encoders.product[Record]
 
    val ds1 = spark.createDataset(
      spark.sparkContext
        .parallelize(input1, partCount)
    )
 
    va


l ds2 = spark.createDataset(
      spark.sparkContext
        .parallelize(input2, partCount)
    )
 
    val ds3 = ds1.join(ds2, Seq("id"))
    val l = ds3.count()
 
    val incomingPartitions = ds3.rdd.getNumPartitions
    log.info(s"Num partitions ${incomingPartitions}")
  {code}
 

Spark UI for the same job with AQE,  !Screenshot 2023-07-11 at 9.36.14 AM.png!

 

Spark UI for the same job without AQE:

 

!Screenshot 2023-07-11 at 9.36.19 AM.png!

 

This is causing unexpected regression in our jobs when we try to enable AQE for our jobs in production. We use spark 3.1 in production, but I can see the same behavior in spark 3.2 from the console as well

 

!image2.png!
Bug: Migrate Buf remote generation alpha to remote plugins
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Jul/23 06:17
Affects Version/s: 3.4.1

Buf unsupported remote generation alpha at now. Please refer [https://buf.build/docs/migration-guides/migrate-remote-generation-alpha/] . We should migrate Buf remote generation alpha to remote plugins by follow the guide.
Bug: exclude junit5 deps from jersey-test-framework-provider-simple
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Jul/23 15:28
Affects Version/s: 3.5.0

SPARK-44316 upgrade Jersey from 2.36 to 2.40. Jersey 2.38 start to use [Junit5 instead of Junit4|https://github.com/eclipse-ee4j/jersey/pull/5123], Spark core module uses `org.glassfish.jersey.test-framework.providers:jersey-test-framework-provider-simple:2.40`, which cascades and introduces the dependencies of Junit5, this causes Java tests no longer be executed when performing maven tests on the core module.

run `mvn clean install -pl core -am`

 
{code:java}
[INFO] --- maven-surefire-plugin:3.1.2:test (default-test) @ spark-core_2.12 ---
[INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO] 
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-surefire-plugin:3.1.2:test (test) @ spark-core_2.12 ---
[INFO] Skipping execution of surefire because it has already been run for this configuration{code}
Bug: Broadcast Joins taking up too much memory
Status: Open | Priority: Major | Resolution: 
Created: 11/Jul/23 18:02
Affects Version/s: 3.4.1

Context: After migrating to Spark 3 with AQE, we saw a significant increase in driver and executor memory usage in our jobs which contains star joins. By analyzing heapdump, we saw that majority of the memory was being taken up by {{UnsafeHashedRelation}} used for broadcast joins; in this case there were 92 broadcast joins in the query.

!screenshot-1.png|width=851,height=70!

This took up over 6GB of total memory, even though every table being broadcasted was around ~1MB and hence should only have been ~100MB total. I found that this is because {{BytesToBytesMap}} used within {{UnsafeHashedRelation}} allocates memory in ["pageSize" increments|https://github.com/apache/spark/blob/37aa62f629e652ed70505620473530cd9611018e/core/src/main/java/org/apache/spark/memory/MemoryConsumer.java#L117] which in our case was 64MB. Based on the [default page size calculation|https://github.com/apache/spark/blob/37aa62f629e652ed70505620473530cd9611018e/core/src/main/scala/org/apache/spark/memory/MemoryManager.scala#L251], this should be the case for any container with > 1 GB of memory (assuming executor.cores = 1) which is far too common. Thus in our case, most of the memory requested by {{BytesToBytesMap}} was un-utilized with just trailing 0s.

!screenshot-2.png|width=389,height=101!

I think this is a major inefficiency for broadcast joins (especially star joins). I think there are a few ways to tackle the problem.
1) Reduce {{spark.buffer.pageSize}} globally to a lower value. This does reduce the memory consumption of broadcast joins, but I am not sure what it implies for the rest of Spark machinery
2) Add a "finalize" operation to {{BytesToBytesMap}} which is called after all values are added to the map and allocates a new page only for the required bytes. 
3) Enhance the serialization of {{BytesToBytesMap}} to record the number of keys and values, and use those during deserialization to only request the required memory.
4) Use a lower page size for certain {{BytesToBytesMap}} based on the estimated data size of broadcast joins.

I believe Option 3 would be simple enough to implement and I have a POC PR which I will post soon, but I am interested in knowing other people's thoughts here.
Bug: Add pyspark_testing module for GHA tests
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Jul/23 17:52
Affects Version/s: 3.5.0

SPIP: https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
Bug: Display percent of unequal rows in DataFrame comparison
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Jul/23 19:38
Affects Version/s: 3.5.0

SPIP: https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
Bug: Improve AQE required distribution (sort order) to auto-matically grow scope (or use previous sort)
Status: Open | Priority: Major | Resolution: 
Created: 10/Jul/23 18:04
Affects Version/s: 3.5.0

With new versions of Iceberg and other catalogs, Spark now can have sort order (or distribution) requirements pushed up from the storage level.

 

While sort(a,b,c) does satisfy sort(a,b) we don't automatically extend the scope to sort(a,b,c) even when sort(a,b) does not have sufficient cardinality. This can result in excessively large partitions during writes.
Bug: Any fields set to Any.getDefaultInstance cause exceptions.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Jul/23 01:01
Affects Version/s: 3.4.1

Protobuf functions added support for converting `Any` fields to json strings. 

It uses Protobuf's built in `JsonFormat` to covert to JSON.

JsonFormat fails to handled the fields when they are set to `Any.getDefaultInstance()` in the original message. This fails only while using descriptor set, but does not fail while using Java classes. Since using descriptor files is the common case, this can be blocker.