av9ash/GitBugs huggingface dataset:
Bug: ITestS3SelectLandsat timeout after 10 minutes
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 02/Aug/22 14:51
Affects Version/s: 3.4.0

timeout doing a full read of the s3 select file through the gzip codec.

{code}
[ERROR] testSelectSeekFullLandsat(org.apache.hadoop.fs.s3a.select.ITestS3SelectLandsat)  Time elapsed: 600.006 s  <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 600000 milliseconds
	at java.lang.Throwable.getStackTraceElement(Native Method)
	at java.lang.Throwable.getOurStackTrace(Throwable.java:828)
	at java.lang.Throwable.getStackTrace(Throwable.java:817)
	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.log4j.spi.LocationInfo.<init>(LocationInfo.java:139)
	at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)
	at org.apache.log4j.helpers.PatternParser$LocationPatternConverter.convert(PatternParser.java:500)
	at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)
	at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)
	at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
	at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
	at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
	at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
	at org.apache.log4j.Category.callAppenders(Category.java:206)
	at org.apache.log4j.Category.forcedLog(Category.java:391)
	at org.apache.log4j.Category.log(Category.java:856)
	at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:230)
	at org.apache.hadoop.util.DurationInfo.close(DurationInfo.java:101)
	at org.apache.hadoop.fs.s3a.Invoker.once(Invoker.java:123)
	at org.apache.hadoop.fs.s3a.select.SelectInputStream.read(SelectInputStream.java:246)
	at org.apache.hadoop.fs.s3a.select.SelectInputStream.seek(SelectInputStream.java:324)
	at org.apache.hadoop.fs.FSDataInputStream.seek(FSDataInputStream.java:73)
	at org.apache.hadoop.fs.s3a.select.AbstractS3SelectTest.seek(AbstractS3SelectTest.java:701)
	at org.apache.hadoop.fs.s3a.select.ITestS3SelectLandsat.testSelectSeekFullLandsat(ITestS3SelectLandsat.java:427)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.j

{code}
Bug: Limit stacked call of one connection in client to avoid possible oom in server
Status: Open | Priority: Major | Resolution: 
Created: 03/Aug/22 16:26

In our prod environment, we encountered an accident that JN OOM because Server#Connection#responseQueue used 97% memory.

After analyzed the memory of JN and found that there are 2w+ called stacked in one Server#Connection#responseQueue, because the network between NN and JN jitters with some tcp packet loss.

!image-2022-08-04-00-22-28-865.png|width=561,height=254!

!image-2022-08-04-00-23-18-427.png|width=559,height=356!

 

In this case, I think Client.java should support limit the stacked calls of one connection to avoid the possible OOM in Server.  When the number of stacked calls is more than the limit size, we can just throw one IOException to the method caller.
Bug: Fix/Improve DistCp doc
Status: Open | Priority: Major | Resolution: 
Created: 30/Jul/22 05:37

Fix/Improve stuff in DistCp doc:
 * Missing Headings from the index like (DistCp and Object Stores)
 * Add about -delete along with -update in example for Object Store usage.
 * Check the usage description for -update. It says it matches blocksize as well, which isn't true unless you specify -pb and if you do so, for cloud storages it would overwrite always.(AFAIK) need to double check.

And if possible other improvements
Bug: Retarget solution file to VS2019
Status: Resolved | Priority: Major | Resolution: Abandoned
Created: 23/Jul/22 18:43
Affects Version/s: 3.4.0

The Visual Studio version used by winutils and native components in Hadoop common are quite old. We need to retarget the solution and vcxproj files to use the latest version (Visual Studio 2019 as of this writing).
Bug: Support for hadoop-aws with aws-java-sdk-bundle with version greater than 1.12.220
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 20/Jul/22 08:37

There are CVEs like  CVE-2021-37137  and many, listed from aws-java-sdk-bundle with version 1.11.375 and the fix is available in versions higher than 1.12.220. It will be great if we have a hadoop-aws with aws-java-sdk-bundle.jar with latest version. Will you be able to provide the same? If so may I know approximately when can I expect it?
Bug: Fix failure of instanciation of s3gatewayrequestlog appender due to lack of HttpRequestLogAppender
Status: Resolved | Priority: Major | Resolution: Invalid
Created: 28/Jul/22 07:49

{noformat}
$ bin/hadoop version
log4j:ERROR Could not instantiate class [org.apache.hadoop.http.HttpRequestLogAppender].
java.lang.ClassNotFoundException: org.apache.hadoop.http.HttpRequestLogAppender
        at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:264)
        at org.apache.log4j.helpers.Loader.loadClass(Loader.java:198)
        at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:327)
        at org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:124)
        at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:785)
        at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
        at org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672)
        at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516)
        at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580)
        at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)
        at org.apache.log4j.LogManager.<clinit>(LogManager.java:127)
        at org.slf4j.impl.Log4jLoggerFactory.<init>(Log4jLoggerFactory.java:66)
        at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:72)
        at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:45)
        at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
        at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
        at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417)
        at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362)
        at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
        at org.apache.hadoop.util.VersionInfo.<clinit>(VersionInfo.java:37)
log4j:ERROR Could not instantiate appender named "s3gatewayrequestlog".
Hadoop 3.4.0-SNAPSHOT
Source code repository Unknown -r c92ff0b4f1135e84527e25087d9cc65250bd0222
Compiled by rocky on 2022-07-27T23:17Z
Compiled with protoc 3.7.1
From source with checksum 486fac66d9b4349cc0fd3d5e8bc38e40
This command was run using /home/rocky/dist/hadoop-3.4.0-SNAPSHOT/share/hadoop/common/hadoop-common-3.4.0-SNAPSHOT.jar
{noformat}
Bug: Enable TLS in RPC Client / Server - Work Description
Status: Open | Priority: Major | Resolution: 
Created: 27/Jul/22 04:56

This Jira has been created to describe the work happening in HADOOP-15980. 

 

In acknowledgement of [~daryn] 's initial contribution that I used to build the final TLS implementation, I have retained HADOOP-15980 in his name.

 

However this results in me not being able to upload design documents to the JIRA. Hence I have created this subtask in which I will upload the design documents and link them to HADOOP-15980.

 

[^Securing Hadoop RPC using SSL.pdf]
Bug: Echo java process's parent pid to the pid file intermediate state
Status: Patch Available | Priority: Major | Resolution: 
Created: 19/Jul/22 08:03
Affects Version/s: 3.3.1

In hadoop-function.sh file，there is hadoop_start_daemon and hadoop_start_daemon_wrapper functions.

hadoop_start_daemon_wrapper invoke hadoop_start_daemon and put it to background.

 

In  hadoop_start_daemon function, echo $$ > pidfile，cause this scenario

because hadoop_start_daemon is in a subshell by ampersand, and $ expands to the process ID of the current shell, not the subshell.
Bug: Unable to access data from S3 bucket over a vpc endpoint - 400 bad request
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 13/Jul/22 11:00

We are trying to write to S3 bucket which has policy with specific IAM Users, SSE and endpoint.  So this bucket has 2 endpoints mentioned in policy : gateway endpoint and interface endpoint.

 

When we use gateway endpoint which is general one: [https://s3.us-east-1.amazonaws.com|https://s3.us-east-1.amazonaws.com/] => spark code executes successfully and writes to S3 bucket

But when we use interface endpoint (which we have to use ideally): [https://bucket.vpce-<>.s3.us-east-1.vpce.amazonaws.com|https://bucket.vpce-%3C%3E.s3.us-east-1.vpce.amazonaws.com/] => spark code throws an error as :

 

py4j.protocol.Py4JJavaError: An error occurred while calling o91.save.

: org.apache.hadoop.fs.s3a.AWSBadRequestException: doesBucketExist on <BUCKET NAME>: com.amazonaws.services.s3.model.AmazonS3Exception: Bad Request (Service: Amazon S3; Status Code: 400; Error Code: 400 Bad Request; Request ID: BA67GFNR0Q127VFM; S3 Extended Request ID: BopO6Cn1hNzXdWh89hZlnl/QyTJef/1cxmptuP6f4yH7tqfMO36s/7mF+q8v6L5+FmYHXbFdEss=; Proxy: null), S3 Extended Request ID: BopO6Cn1hNzXdWh89hZlnl/QyTJef/1cxmptuP6f4yH7tqfMO36s/7mF+q8v6L5+FmYHXbFdEss=:400 Bad Request: Bad Request (Service: Amazon S3; Status Code: 400; Error Code: 400 Bad Request; Request ID: BA67GFNR0Q127VFM; S3 Extended Request ID: BopO6Cn1hNzXdWh89hZlnl/QyTJef/1cxmptuP6f4yH7tqfMO36s/7mF+q8v6L5+FmYHXbFdEss=; Proxy: null)

 

Attaching the pyspark code and exception trace

  [^spark_s3.txt]

^[^spark_s3_vpce_error.txt]^
Bug: Fix create-release to address removal of GPG_AGENT_INFO in branch-3.2
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jul/22 04:08
Affects Version/s: 3.2.3

gpg v2.1 and above does not export GPG_AGENT_INFO. create-release script need to export the info by itself to make {{--sign}} work. It was addressed as part of HADOOP-16797 in branch-3.3 and trunk. Since we can not backport aarch64 support to branch-3.2, I filed this issue for branch-3.2 only.
Bug: Shouldn't relocate org/wildfly/openssl in shaded client
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 09/Jul/22 15:38
Affects Version/s: 3.3.2

We shouldn't shade {{org.wildfly.openssl}} since it's provided dependency and will give error like the following:
{code}
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/hadoop/shaded/org/wildfly/openssl/OpenSSLProvider
        at org.apache.hadoop.security.ssl.DelegatingSSLSocketFactory.bindToOpenSSLProvider(DelegatingSSLSocketFactory.java:196)
        at org.apache.hadoop.security.ssl.DelegatingSSLSocketFactory.initializeSSLContext(DelegatingSSLSocketFactory.java:169)
        at org.apache.hadoop.security.ssl.DelegatingSSLSocketFactory.<init>(DelegatingSSLSocketFactory.java:134)
        at org.apache.hadoop.security.ssl.DelegatingSSLSocketFactory.initializeDefaultFactory(DelegatingSSLSocketFactory.java:105)
        at org.apache.hadoop.fs.s3a.impl.NetworkBinding.bindSSLChannelMode(NetworkBinding.java:82)
        at org.apache.hadoop.fs.s3a.S3AUtils.initProtocolSettings(S3AUtils.java:1347)
        at org.apache.hadoop.fs.s3a.S3AUtils.initConnectionSettings(S3AUtils.java:1302)
        at org.apache.hadoop.fs.s3a.S3AUtils.createAwsConf(S3AUtils.java:1259)
        at org.apache.hadoop.fs.s3a.DefaultS3ClientFactory.createS3Client(DefaultS3ClientFactory.java:114)
        at org.apache.hadoop.fs.s3a.S3AFileSystem.bindAWSClient(S3AFileSystem.java:846)
        at org.apache.hadoop.fs.s3a.S3AFileSystem.initialize(S3AFileSystem.java:503)
{code}
Bug: Support AWS IAM Identity Centre (prev. AWS SSO) for providing credentials to S3A
Status: Open | Priority: Minor | Resolution: 
Created: 20/Jul/22 12:18
Affects Version/s: 3.3.3

HADOOP-18073 was opened regarding upgrading AWS SDK to V2 which supports a credential provider for AWS SSO. Opening this ticket to track that feature explicitly separately from the SDK upgrade.

Related SDK issue for AWS SSO support in AWS SDK for Java V1: [https://github.com/aws/aws-sdk-java/issues/2434]

In particular, from [https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html], when to set 'fs.s3a.aws.credentials.provider', it must be "com.amazonaws.auth.AWSCredentialsProvider". We would like to support "software.amazon.awssdk.auth.credentials.ProfileCredentialsProvider" which supports AWS SSO, so users only need to authenticate once.
Bug: Update commons-math3 from 3.1.1 to 3.6.1.
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Jul/22 04:54
Affects Version/s: 3.4.0

I found that commons-math3 can be upgraded from 3.1.1 to 3.6.1. Try to upgrade, local compilation and verification are correct.
Bug: tag FSDataInputStream.getWrappedStream() @Public/@Stable
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 12/Jul/22 11:08
Affects Version/s: 3.3.3

PARQUET-2134 shows external code is calling FSDataInputStream.getWrappedStream()

tag ase @Public/@Stable as it has been stable and we should acknowledge that use & know not to break it
Bug: S3A prefetching: Error logging during reads
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 20/Jul/22 10:37
Affects Version/s: 3.4.0

Look at how errors during read are logged, current implementation could flood logs with stack traces on failures.

proposed
 * errors in prefetch only logged at info with error text but not stack
 * full stack logged at debug

but: we do want the most recent failure to be raised on the next read() on the stream when there is no data in the cache.
Bug: Update commons-csv from 1.0 to 1.9.0.
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Jul/22 02:27
Affects Version/s: 3.4.0

commons-csv 1.0 is a very old jar, mvnrepository shows this jar as the 2014 version, I have compiled and tested locally, I think this jar can be upgraded to commons-csv 1.9 version.

The link to the release note is as follows:
[https://commons.apache.org/proper/commons-csv/changes-report.html]

We can see that the new version fixes some issues.

I read the code used, we use header related methods. We found that many header-related methods have been upgraded.

*Release 1.1 – 2014-11-16*
CSVFormat#withHeader doesn't work well with #printComment, add withHeaderComments(String...).
CSVFormat.EXCEL should ignore empty header names.

*Release 1.2 – 2015-08-24*
CSVFormat.with* methods clear the header comments.

*Release 1.3 – 2016-05-09*
Add shortcut method for using first record as header to CSVFormat.
Add withHeader(Class<? extends Enum>) to CSVFormat.
CSVPrinter doesn't skip creation of header record if skipHeaderRecord is set to true.
Add IgnoreCase option for accessing header names.

*Release 1.5 – 2017-09-03*
Fix incorrect method name 'withFirstRowAsHeader' in user guide.

*Release 1.7 – 2019-06-01*
Cannot get headers in column order from CSVRecord.

*Release 1.8 – 2020-02-01*
CSVFormat#validate() does not account for allowDuplicateHeaderNames.
A single empty header is allowed when not allowing empty column headers.

*Release 1.9.0 – 2020-07-24*
Add possibility to use ResultSet header meta data as CSV header.
Bug: Implement readFully(long position, byte[] buffer, int offset, int length)
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Jul/22 13:41
Affects Version/s: 3.4.0

Implement readFully(long position, byte[] buffer, int offset, int length) in PrefetchingInputStream, as it currently uses FSInputStream's [readFully|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FSInputStream.java#L136] which calls read(long position, byte[] buffer, int offset, int length).

This read then seeks to the position (which is ok), but then seeks back to the original starting position at the end (so always seeking back to 0). this is pretty bad for the prefetching implementation as it means lots of caching to disk and getting blocks from disk. 

when backporting. follow with HADOOP-18531
Bug: Upgrade AWS SDK to V2 - Prerequisites 
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 01/Aug/22 12:15
Affects Version/s: 3.3.5

We want to update the AWS SDK to V2, before we do this we should warn on things that will no longer supported. The following changes should be made:

 
 * [getAmazonS3Client()|https://github.com/apache/hadoop/blob/221eb2d68d5b52e4394fd36cb30d5ee9ffeea7f0/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/S3AFileSystem.java#L1174] - Warn that this method will be removed 
 * [initCustomSigners()|https://github.com/apache/hadoop/blob/03cfc852791c14fad39db4e5b14104a276c08e59/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/auth/SignerManager.java#L65] - Warn that the interface is changing, any custom signers will need to be updated

 * [bindAWSClient|https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/S3AFileSystem.java#L840] - If DT is enabled, warn that credential providers interface is changing, any custom cred providers used in binding classes will need to be updated
 *  [buildAWSProviderList|https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/S3AUtils.java#L618] - if any SDK V1 cred providers are in this list, warn that these will be removed
 * [S3ClientFactory|https://github.com/apache/hadoop/blob/221eb2d68d5b52e4394fd36cb30d5ee9ffeea7f0/hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/S3ClientFactory.java] - Update javadocs to say this interface will be replaced by a V2 client factory, mark interface deprecated?
Bug: [ABFS]: ITestAbfsManifestCommitProtocol  fails on nonHNS configuration
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 18/Aug/22 05:51
Affects Version/s: 3.3.5

ITestAbfsRenameStageFailure fails for NonHNS-SharedKey configuration.

Failure:
[ERROR] ITestAbfsRenameStageFailure>TestRenameStageFailure.testResilienceAsExpected:126 [resilient commit support] expected:<[tru]e> but was:<[fals]e>

RCA:
ResilientCommit looks for whether etags are preserved in rename, if not then it throws an exception and the flag for resilientCommitByRename stays null, leading ultimately to the test failure

Mitigation:
Since, etags are not preserved in the case of rename in nonHNS account, required value for rename resilience should be False, as resilient commits cannot be made. Thus, requiring a True value for requireRenameResilience for nonHNS account is not a valid case. Hence, as part of this task, we shall set correct value of False for requireRenameResilience for nonHNS account.
Bug: Add a re-queue metric to RpcMetrics.java to quantify the number of re-queue RPCs
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 08/Sep/22 01:23
Affects Version/s: 3.4.0

Add a reQueue metric to RpcMetrics.java to quantify the number of RPCs reQueued.

Because Observer NameNode will re-queue the rpc if the call processing should be postponed.

 

There is no any metric to quantify the number of re-queue RPCs, so I think we should do it.
Bug: Limit the findbugs suppression IS2_INCONSISTENT_SYNC to S3AFileSystem field
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 22/Sep/22 19:19
Affects Version/s: 3.4.0

Limit the findbugs suppression IS2_INCONSISTENT_SYNC to S3AFileSystem field futurePool to avoid letting it discover other synchronization bugs.
Bug: An unhandled ArrayIndexOutOfBoundsException in DefaultStringifier.storeArray() if provided with an empty input
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Sep/22 20:39
Affects Version/s: 3.3.4

The code throws an unhandled ArrayIndexOutOfBoundsException when method _storeArray_ of DefaultStringifier.java is called with an empty array as input.
Bug: ITestS3AFileSystemStatistic failure in prefetch feature branch
Status: Open | Priority: Minor | Resolution: 
Created: 02/Aug/22 13:11
Affects Version/s: 3.4.0

testing the rebased prefetch feature branch; got a failure in ITestS3AFileSystemStatistic
 
{code}
tics.ITestS3AFileSystemStatistic
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.489 s <<< FAILURE! - in org.apache.hadoop.fs.s3a.statistics.ITestS3AFileSystemStatistic
[ERROR] testBytesReadWithStream(org.apache.hadoop.fs.s3a.statistics.ITestS3AFileSystemStatistic)  Time elapsed: 1.489 s  <<< FAILURE!
java.lang.AssertionError: Mismatch in number of FS bytes read by InputStreams expected:<2048> but was:<69537130>
        at org.apache.hadoop.fs.s3a.statistics.ITestS3AFileSystemStatistic.testBytesReadWithStream(ITestS3AFileSystemStatistic.java:72)


{code}
that;s 64MB + ~237 kb, the kind of values you would get from prefetching

but, prefetch was disabled in this test run.

maybe its just the fs stats aren't being reset between test cases
Bug: scan detected CVE-2021-37136 and CVE-2021-37137 in netty.io_netty_codec
Status: Resolved | Priority: Minor | Resolution: Done
Created: 20/Sep/22 06:35

Our security scan detected CVE-2021-37136 and CVE-2021-37137 in io.netty_netty

 
|Component|Version|CVE|Fixed in|
|io.netty_netty|3.10.6|CVE-2021-37136|4.1.68|
|io.netty_netty|3.10.6|CVE-2021-37137|4.1.68|
|org.yaml_snakeyaml|1.26|CVE-2022-25857|1.31|
Bug: [ABFS]: RenameFilePath Source File Not Found (404) error in retry loop
Status: Resolved | Priority: Minor | Resolution: Duplicate
Created: 26/Aug/22 12:38

RenameFilePath on its first try receives a Request timed out error with code 500. On retrying the same operation, a Source file not found (404) error is received. 

Possible mitigation: Check whether etags remain the same before and after the retry and accordingly send an Operation Successful result, instead of source file not found.