av9ash/GitBugs huggingface dataset:
Bug: FS/FC createFile() builder to add a lazy-check option for async probes of the store
Status: Open | Priority: Minor | Resolution: 
Created: 05/Feb/20 10:04
Affects Version/s: 3.3.0

For object stores, file creation can triggers checks for: path being to a file, path not being a directory, parent path existing.

These are all done before an output stream is returned -even though nothing may be manifest in the remote store until the screen is flashed or closed.

If we supported lazy checks we could do those probes against the store while the application was actually generating data to write.

Changing the behaviour of open() would be too fundamental. What we can do is add a new option to the createFile() builder which stores can support. When set, the caller is declaring they are happy with late reporting of failures -with any problems surfacing during a write/flush/close. It is notable with S3A permissions issues only surface later on anyway.
Bug: Update ADLS client credential creation docs
Status: Open | Priority: Minor | Resolution: 
Created: 28/Feb/20 13:06
Affects Version/s: 3.3.0

Azure portal has moved things around, renamed concepts, and the ADLS config generation instructions don't match the UI any more

Update ADLS client credential creation docs to match the current Azure portal.

*and add a datestamp of when these docs were current*
Bug: ABFS: Delegation SAS generator for integration with Ranger
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 11/Mar/20 02:38
Affects Version/s: 3.2.1

HADOOP-16730 added support for Shared Access Signatures (SAS).  Azure Data Lake Storage Gen2 supports a new SAS type known as User Delegation SAS.  This Jira tracks an update to the ABFS driver that will include a Delegation SAS generator and tests to validate that this SAS type is working correctly with the driver.
Bug: ITestDynamoDBMetadataStore.testTableVersioning failure -DDB deleteItem consistency?
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 14/Jan/20 14:37
Affects Version/s: 3.3.0

transient failure of ITestDynamoDBMetadataStore.testTableVersioning; the deleted table version record was still there.

Looks like the delete is EC; finally I hit a consistency event

Proposed: the test iterates a bit awaiting the exception
Bug: For AzureNativeFS, when BlockCompaction is enabled, FileSystem.create(path).close() would throw exception.
Status: Open | Priority: Minor | Resolution: 
Created: 19/Feb/20 17:32
Affects Version/s: 2.9.2

For AzureNativeFS, when BlockCompaction is enabled, FileSystem.create(path).close() would throw blob not existed exception.

Block Compaction Setting: fs.azure.block.blob.with.compaction.dir
Exception is thrown from close(), this would happen when no write happened. When actually write any content in the file, same context close() won't trigger the exception. 

When BlockCompaction is not enabled, this issue won't happen. 

Call Stack:

org.apache.hadoop.fs.azure.AzureException: Source blob _$azuretmpfolder$/956457df-4a3e-4285-bc68-29f68b9b36c4test1911.log does not exist.
org.apache.hadoop.fs.azure.AzureException: Source blob _$azuretmpfolder$/956457df-4a3e-4285-bc68-29f68b9b36c4test1911.log does not exist. 
at org.apache.hadoop.fs.azure.AzureNativeFileSystemStore.rename(AzureNativeFileSystemStore.java:2648) 
at org.apache.hadoop.fs.azure.AzureNativeFileSystemStore.rename(AzureNativeFileSystemStore.java:2608) 
at org.apache.hadoop.fs.azure.NativeAzureFileSystem$NativeAzureFsOutputStream.restoreKey(NativeAzureFileSystem.java:1199) 
at org.apache.hadoop.fs.azure.NativeAzureFileSystem$NativeAzureFsOutputStream.close(NativeAzureFileSystem.java:1068) 
at org.apache.hadoop.fs.FSDataOutputStream$PositionCache.close(FSDataOutputStream.java:72) 
at org.apache.hadoop.fs.FSDataOutputStream.close(FSDataOutputStream.java:106)
Bug: AWS AssumedRoleCredentialProvider needs ExternalId add
Status: Resolved | Priority: Minor | Resolution: Invalid
Created: 15/Jan/20 16:56
Affects Version/s: 3.2.1

AWS has added a security feature to the assume-role function in the form of the "ExternalId" key in the AWS Java SDK {{STSAssumeRoleSessionCredentialsProvider.Builder}} class.  To support this security feature, the hadoop aws {{AssumedRoleCredentialProvider}} needs a patch to include this value from the configuration as well as an added Constant to the {{org.apache.hadoop.fs.s3a.Constants}} file.
Bug: ITestS3GuardOutOfBandOperations.testListingDelete failing on versioned bucket
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Mar/20 17:15
Affects Version/s: 3.3.0

Failure in versioned bucket on  testListingDelete[auth=true](org.apache.hadoop.fs.s3a.ITestS3GuardOutOfBandOperations) ; looks like an error in one of the asserts where something is failing in the open().get() not the read, because we don't pass in a status to the rawFS.
Bug: Backport HADOOP-10848. Cleanup calling of sun.security.krb5.Config to branch-3.2
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Mar/20 12:22

Backport HADOOP-10848 to lower branches like branch-3.2 so applications using older hadoop jars (e.g. Ozone) can get rid of the annoying message
{code}
WARNING: Illegal reflective access by org.apache.hadoop.security.authentication.util.KerberosUtil (file:/opt/hadoop/share/ozone/lib/hadoop-auth-3.2.0.jar) to method sun.security.krb5.Config.getInstance()
{code}
when running with JDK11+
Bug: mkdir on s3a should not be sensitive to trailing '/'
Status: Resolved | Priority: Minor | Resolution: Duplicate
Created: 13/Mar/20 15:57

I would have expected to create the directory for both calls:

{code}
[hive@hiveserver2-0 lib]$ hdfs dfs -mkdir s3a://qe-s3-bucket-mst-xfpn-dwx-external/custom-jars2/
/usr/bin/hdfs: line 4: /usr/lib/bigtop-utils/bigtop-detect-javahome: No such file or directory
log4j:WARN No appenders could be found for logger (org.apache.hadoop.util.Shell).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
mkdir: get on s3a://qe-s3-bucket-mst-xfpn-dwx-external/custom-jars2/: com.amazonaws.services.dynamodbv2.model.AmazonDynamoDBException: One or more parameter values were invalid: An AttributeValue may not contain an empty string (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ValidationException; Request ID: 1AE0KA2Q5ADI47R75N8BDJE973VV4KQNSO5AEMVJF66Q9ASUAAJG): One or more parameter values were invalid: An AttributeValue may not contain an empty string (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ValidationException; Request ID: 1AE0KA2Q5ADI47R75N8BDJE973VV4KQNSO5AEMVJF66Q9ASUAAJG)
[hive@hiveserver2-0 lib]$ hdfs dfs -mkdir s3a://qe-s3-bucket-mst-xfpn-dwx-external/custom-jars2
/usr/bin/hdfs: line 4: /usr/lib/bigtop-utils/bigtop-detect-javahome: No such file or directory
log4j:WARN No appenders could be found for logger (org.apache.hadoop.util.Shell).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
[hive@hiveserver2-0 lib]$ 
{code}
Bug: distcp copy calls getFileStatus() needlessly and can fail against S3
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 21/Mar/20 18:14
Affects Version/s: 3.0.0

Distcp to AWS s3 was working fine on CDH 5.16 with distcp 2.6.0. but after upgrade to CDH 6.3 which comes with distcp-3.0 JAR which is through error as below.

The same error with repeats on Hadoop-distcp-3.2.1.jar as well. Tried with -direct option in 3.2.1, still same error.

 

Error: java.io.FileNotFoundException: No such file or directory: s3a://XXXXXXXXXXXXX/part-00012-baa6a706-3816-4dfa-ba07-0fb56fd38178-c000.snappy.parquet
 at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:2255)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2149)
 at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
 at org.apache.hadoop.tools.util.DistCpUtils.preserve(DistCpUtils.java:203)
 at org.apache.hadoop.tools.mapred.CopyMapper.map(CopyMapper.java:220)
 at org.apache.hadoop.tools.mapred.CopyMapper.map(CopyMapper.java:48)
 at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:146)
 at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:799)
 at org.apache.hadoop.mapred.MapTask.run(MapTask.java:347)
 at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:174)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.Subject.doAs(Subject.java:422)
 at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875)
 at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:168)
Bug: catch and downgrade all exceptions trying to load openssl native libs through wildfly
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 31/Jan/20 13:20
Affects Version/s: 3.2.1

I am getting reports of problems loading the wildfly/openSSL binding even on a build which should have HADOOP-16405 on. I'm not sure that really is the case, but given that we have had problems here which surface aa NPEs, and we may end up having other linkage problems in future -I think we should catch all exceptions raised trying to instantiate the wildfly SSL bindings and fall back to the JVM. 

I do want to log@warn here, because it is a sign of a problem. A full stack can come in at debug
Bug: Backport HADOOP-16890- "ABFS: Change in expiry calculation for MSI token provider" & HADOOP-16825 "ITestAzureBlobFileSystemCheckAccess failing" to branch-2
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 23/Mar/20 20:57
Affects Version/s: 3.3.0

Backport "ABFS: Change in expiry calculation for MSI token provider" to branch-2
Bug: ITestS3GuardOutOfBandOperations failing on versioned S3 buckets
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 11/Feb/20 17:56
Affects Version/s: 3.3.0

org.apache.hadoop.fs.s3a.ITestS3GuardOutOfBandOperations.testListingDelete[auth=true]

failing because the deleted file can still be read when the s3guard entry has the versionId.

Proposed: if the FS is versioned and the file status has versionID then we switch to tests which assert the file is readable, rather than tests which assert it isn't there
Bug: Distcp print wrong log info when use -log
Status: Patch Available | Priority: Minor | Resolution: 
Created: 25/Mar/20 09:30
Affects Version/s: 3.1.1

when run distcp with -log /logpath -v, distcp will print copy status and file info to /logpath, but print log with wrong file zise. The logs print as follows:

FILE_COPIED: source=hdfs://ns1/test/stax2-api-3.1.4.jar, size=161867 --> target=hdfs://ns1/tmp/target/stax2-api-3.1.4.jar, size=0

As I analysis ,the root cause is as follows:

targrtFileStatus got before copying. So targrtFileStatus is null. Here should get targrtFileStatus again after file copying.

!image-2020-03-25-17-28-33-394.png!
Bug: fs.azure.user.agent.prefix adds customisation as suffix.
Status: Open | Priority: Minor | Resolution: 
Created: 04/Mar/20 08:45
Affects Version/s: 3.2.0

Setting fs.azure.user.agent.prefix adds customization as suffix

eg: when I set `fs.azure.user.agent.prefix` to my email the user agent value is 
Azure Blob FS/1.0 (DBFS) (JavaJRE 1.8.0_232; Linux 4.15.0-1050-azure; SunJSSE-1.8) arunravimv@gmail.com
 I believe this is inconsistent with the similar setting in AWS S3 fs.s3a.user.agent.prefix where the customization is added as a prefix. I believe that it would be great if we make this consistent with configuration name.

 

The proposed change is to fix the AbfsClient.initializeUserAgent.

 

We use a user agent information available in cloud service logs for extended tracking.
Bug: Update HdfsDesign.md to reduce ambiguity
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Mar/20 20:34

A proposed update to [https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HdfsDesign.md|http://example.com/] in the section "Replica Placement: The First Baby Steps" 4th paragraph, 2nd last line.

The sentence is leading to ambiguity of reader.

Considering the statement segmented in 3 parts by the commas:
 # the first part talks about "one thirds of replicas";
 # the second part talks about "two thirds of replicas"
 # the third part talking about "the other third" is leading to ambiguity when one thirds and two thirds have already accounted for the whole.

Proposed solution:

Getting rid of the third part or rephrasing entire sentence to capture the overall essence of the sentence.

In other words, replacing 

_One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks._

with

-_One third of replicas are on one node, two thirds of replicas are on one rack._-
{quote}{{Two replicas are on different nodes of one rack and the remaining replica is on a node of one of the other racks.}}
{quote}
In addition to this, found 2 more sentences in same paragraph that will be corrected.

1.
{quote}However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three.
{quote}
will replace: does reduce -> does not reduce

2. 
{quote}With this policy, the replicas of a file do not evenly distribute across the racks.
{quote}
will replace: replicas of a file -> replicas of a block 

Please suggest if any additional meaning is getting lost with this replacement.
Bug: Sort fields in ReflectionUtils.java
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Mar/20 10:09
Affects Version/s: 3.3.0

The tests in _org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl#testInitFirstVerifyCallBacks_ and _org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl#testInitFirstVerifyStopInvokedImmediately_ can fail.

java.lang.AssertionError:

Element 0 for metrics expected:<MetricCounterLong{info=MetricsInfoImpl

{name=C1, description=C1 desc}

, value=1}>

but was:<MetricGaugeLong{info=MetricsInfoImpl

{name=G1, description=G1 desc}

, value=2}>

at org.junit.Assert.fail(Assert.java:88)

at org.junit.Assert.failNotEquals(Assert.java:834)

at org.junit.Assert.assertEquals(Assert.java:118)

at org.apache.hadoop.test.MoreAsserts.assertEquals(MoreAsserts.java:60)

at org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl.checkMetricsRecords(TestMetricsSystemImpl.java:439)

at org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl.testInitFirstVerifyCallBacks(TestMetricsSystemImpl.java:178)

 

The root cause of this failure can be analyzed in the following stack trace:

_java.lang.Class.*getDeclaredFields*(Class.java:1916)_
 _org.apache.hadoop.util.ReflectionUtils.getDeclaredFieldsIncludingInherited(ReflectionUtils.java:353)_
 _org.apache.hadoop.metrics2.lib.MetricsSourceBuilder.<init>(MetricsSourceBuilder.java:68)_
 _org.apache.hadoop.metrics2.lib.MetricsAnnotations.newSourceBuilder(MetricsAnnotations.java:43)_
 _org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:223)_
 _org.apache.hadoop.metrics2.impl.TestMetricsSystemImpl.testInitFirstVerifyCallBacks(TestMetricsSystemImpl.java:156)_

The specification about getDeclaredFields() says that "the elements in the returned array are not sorted and are not in any particular order". The documentation is here for your reference: [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredFields--]
 And the behaviour might be different for different JVM versions or vendors

 

The fix is to sort the fields returned by getDeclaredFields() so that the non-deterministic behaviour can be eliminated completely. In this way, the test becomes more stable and it will not suffer from the failure above any more.
Bug: start-build-env.sh behaves incorrectly when username is numeric only
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 10/Feb/20 10:42

When username is numaric only, the build environment does not run correctly.
Here is my case.

{noformat}
~/hadoop$ ./start-build-env.sh
...
Successfully tagged hadoop-build-1649860140:latest

 _   _           _                    ______
| | | |         | |                   |  _  \
| |_| | __ _  __| | ___   ___  _ __   | | | |_____   __
|  _  |/ _` |/ _` |/ _ \ / _ \| '_ \  | | | / _ \ \ / /
| | | | (_| | (_| | (_) | (_) | |_) | | |/ /  __/\ V /
\_| |_/\__,_|\__,_|\___/ \___/| .__/  |___/ \___| \_(_)
                              | |
                              |_|

This is the standard Hadoop Developer build environment.
This has all the right tools installed required to build
Hadoop from source.

I have no name!@fceab279f8d1:~/hadoop$ whoami
whoami: cannot find name for user ID 1112533
I have no name!@fceab279f8d1:~/hadoop$ sudo ls
sudo: unknown uid 1112533: who are you?
{noformat}

I changed {{USER_NAME}} to {{USER_ID}} in the script. Then it worked correctly.
Bug: Test TestGroupsCaching fail if HashSet iterates in a different order
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 06/Feb/20 18:46
Affects Version/s: 3.2.1

The test `testNegativeGroupCaching` can fail if the iteration order of HashSet changes. In detail, the method `assertEquals` (line 331) compares `groups.getGroups(user)` with an ArrayList `myGroups`. The method `getGroups` converts `allGroups` (a HashSet) to a list and it calls iterator in HashSet. However, the iteration is non-deterministic.

This PR proposes to modify HashSet to LinkedHashSet for a deterministic order.
Bug: S3Guard listFiles will not query S3 if all listings are authoritative
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 14/Jan/20 19:28
Affects Version/s: 3.3.0

S3Guard does not respect authoritative metadatastore when listFiles is used with recursive=true. It queries S3 even when given directory tree is 1-level with no nested directories and the parent directory listing is authoritative. S3Guard should check the listings in given directory tree for authoritativeness and not query S3 when all listings in the tree are marked as authoritative in metadata table (given metadatastore is configured to be authoritative.

Below is the description of how the current code works:

S3AFileSystem#listFiles with recursive option, queries S3 even when directory listing is authoritative. FileStatusListingIterator is created with given entries from metadata store [https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/Listing.java#L126] . However, FileStatusListingIterator has an ObjectListingIterator that prefetches from s3 regardless of authoritative listing. We observed this behavior when using DynamDBMetadataStore.

I suppressed the unnecessary S3 calls by providing a dumb listing iterator to listFiles call in the provided patch. Obviously this is not a solution. Just demonstrating the source of the problem.
Bug:  Remove WARN log when ipc connection interrupted in Client#handleSaslConnectionFailure()
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 08/Jan/20 02:15

log info:
{code:java}
// Some comments here
2020-01-07,15:01:17,816 WARN org.apache.hadoop.ipc.Client: Exception encountered while connecting to the server : java.io.InterruptedIOException: Interrupted while waiting for IO on channel java.nio.channels.SocketChannel[connected local=/10.75.13.227:50415 remote=mb2-hadoop-prc-ct06.awsind/10.75.15.99:11230]. 60000 millis timeout left
{code}

With RequestHedgingProxyProvider, one rpc call will send multiple requests to all namenodes. After one request return successfully,  all other requests will be interrupted. It's not a big problem and should not print a warning log.
{code:java}
private synchronized void handleSaslConnectionFailure(
....
LOG.warn("Exception encountered while connecting to "
        + "the server : " + ex);
}


{code}
Bug: Use forkCount and reuseForks parameters instead of forkMode in the config of maven surefire plugin
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 16/Jan/20 11:10

forkMode parameter is now deprecated.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
 
{noformat}
$ find . -name "pom.xml" | xargs grep "forkMode"
./hadoop-tools/hadoop-distcp/pom.xml:          <forkMode>always</forkMode>
./hadoop-hdfs-project/hadoop-hdfs-httpfs/pom.xml:              <forkMode>once</forkMode>
{noformat}
Bug: In TestZKFailoverController, restore changes from HADOOP-11149 that were dropped by HDFS-6440
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 03/Jan/20 21:31
Affects Version/s: 2.10.0

In our automated tests, we are seeing intermittent failures in TestZKFailoverController.  I have been unable to reproduce the failures locally, but in examining the code, I found a difference that may explain the failures.

In trunk, HDFS-6440 ( Support more than 2 NameNodes. Contributed by Jesse Yates.) was checked in before HADOOP-11149. TestZKFailoverController times out), which changed the test added in HDFS-6440.

In branch-2, the order was reversed, and the test that was added in HDFS-6440 does not retain the fixes from HADOOP-11149.

Note that there was also a change from HDFS-10985. (o.a.h.ha.TestZKFailoverController should not use fixed time sleep before assertions.) that was missed in the HDFS-6440 backport.

My proposal is to restore the changes from HADOOP-11149.  I made this change internally and it seems to have fixed the intermittent failures.
Bug: log accepted/rejected fs.s3a.authoritative.path paths @ debug
Status: Open | Priority: Trivial | Resolution: 
Created: 27/Mar/20 10:18
Affects Version/s: 3.3.0

HADOOP-16939 added filtering of auth paths from other buckets. Typos and misconfigs may stop paths being auth when people expect them

Proposed: we log @ debug which paths were accepted, which werent
Bug: Fix Hadoops AWS Integration GitHub links
Status: Resolved | Priority: Trivial | Resolution: Won't Fix
Created: 10/Jan/20 22:11

The links in the "see also" section here point to broken .html links instead of .md links:

[https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-aws/src/site/markdown/tools/hadoop-aws/index.md]
Bug: S3ABlockOutputStream no longer sends progress events in close()
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 01/Aug/24 17:55
Affects Version/s: 3.4.0

We don't get progress events passed through from S3ABlockOutputStream to any Progress instance passed in which doesn't implement ProgressListener

This is due to a signature mismatch between the changed ProgressableListener interface and the {{S3ABlockOutputStream.ProgressListener}} impl.

* critical because distcp jobs will timeout on large uploads without this
* trivial to fix; does need a test
Bug: S3A: Support S3 Conditional Writes
Status: Open | Priority: Major | Resolution: 
Created: 21/Aug/24 18:07

S3 Conditional Write (Put-if-absent) capability is now generally available - [https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/]

 

S3A should allow passing in this put-if-absent header to prevent over writing of files. 

There is a feature branch for this: HADOOP-19256-s3-conditional-writes

+ support etags to allow an overwrite to be restricted to overwriting a specific version. This can be done through a createFile option.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html

Fun fact; third party stores will not reject overwrites if they don't recognise the headers, so there's no way to be sure they are supported without testing.

we need a flag to enable/disable conditional writes which can be exposed in a hasPathCapability()
Bug: upgrade to protobuf-java 3.25.5 due to CVE-2024-7254
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 25/Sep/24 16:49

https://github.com/advisories/GHSA-735f-pc8j-v9w8

Presumably protobuf encoded messages in Hadoop come from trusted sources but it is still useful to upgrade the jar.