(BAF.Error.3) Working on Sell Hub (manually), but not programmatically

[overnightcomputer]

(Note: I'm working in sandbox environment, and haven't tried in production)

The .csv example I'm using:

Action(SiteID=US|Country=US|Currency=USD|Version=1193|CC=UTF-8),Category,Title,Subtitle,ConditionID,C:MPN,C:Brand,C:Model,PicURL,Description,Format,Duration,StartPrice,Quantity,Location,DispatchTimeMax,ShippingProfileName,ReturnProfileName,PaymentProfileName
VerifyAdd,16145,CustomTitleText,CustomSubtitleText,1000,CustomMPNText,Acer,CustomModelText,https://www.impactcomputers.com/image/cache/data/products/1/1103272-200x200.jpg,TestDescriptionText,FixedPrice,GTC,10,10,"US, FL",1,test_fulfillment_policy,test_return_policy,test_payment_policy

I have two accounts. Developer and regular account (where I can upload a file manually).

Uploading file in both ways end in success.

But... When I download a result file from the Sell Hub (manually), it doesn't contain BAF.Error.3. Where on the other hand, programmatically downloaded result file contains BAF.Error.3.

I've tried wrapping every element in double quotes; both "\r\n" and "\n" end of lines; both formats of fields e.g. "CategoryID" and "Category ID".

Here is the content of result file with an error:

Line Number,Action,Status,ErrorCode,ErrorMessage,WarningCode,WarningMessage,Code,Message,ItemID,ReferenceID,ApplicationData,StartTime,EndTime,AuctionLengthFee,BoldFee,BorderFee,BuyItNowFee,CategoryFeaturedFee,CurrencyID,FeaturedFee,FeaturedGalleryFee,FixedPriceDurationFee,GalleryFee,GiftIconFee,HighlightFee,InsertionFee,InternationalInsertionFee,ListingDesignerFee,ListingFee,PhotoDisplayFee,PhotoFee,ProPackBundleFee,ReserveFee,SchedulingFee,SubtitleFee,CustomLabel,PrivateNotes,BasicUpgradePackBundleFee,ValuePackBundleFee,ProPackPlusBundleFee,SellerInventoryID,CrossBorderTradeNorthAmericaFee,CrossBorderTradeGBFee,RefundFromSeller,TotalRefundToBuyer,CorrelationID
 2, ,,Failure,BAF.Error.3,Error occured, try again later!, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 

Here is how I send a file with the Guzzle client:

$options = [
    'multipart' => [
        [
           'name' => 'file',
           'filename' => $filename,
           'contents' => file_get_contents($filepath),
           'headers' => [
               'Content-Type' => 'text/csv'
           ]
        ]
    ]
];
$response = $this->client->post("v1/task/$taskId/upload_file", $options);

If someone can help resolve the issue, I will be thankful.

[shipscript]

@overnightcomputer 

A BAF.Error.3 is one of the most basic errors, indicating the file is not correctly formatted and can not be parsed at all. It can also be caused by a duplicated column.

Your response file is missing the Action field. Instead of VerifyAdd in that location, the field is empty. Thus, I might suggest looking again at your line ends when programmatically uploading.

On the face of it, your file looks fine. Quotes are not needed with your brief strings.  The file reader is particular about line ends, preferring Windows format, and rejecting Mac line ends. I usually code "\n" as line ends.

Additionally, it will not tolerate any characters preceding the Action heading. Older spreadsheets, saved as UTF-8, might prepend special DOM characters to the front of the file, and that will cause failure. Other character encodings are CP1252 or ISO-8859-1 to get around that issue.

However, if you are uploading the same file through both accounts and the upload is successful in both cases, while only the programmatic download of the results file fails, something seems unbalanced. If the upload failed and the download showed the error, that would make more sense. Am I missing any parameters here?

[overnightcomputer]

Uploading file in both cases end in success. But only programmatic downloaded result file shows BAF Error for the uploaded (input) file...

I don't see what is wrong with the example I provided.

I've tried both Windows and Linux(Mac) format of the file, but everything seems the same...

[overnightcomputer]

@shipscript 

Just to note a weird behavior...

1.)   I uploaded a file, that doesn't show BAF Error, manually. 

2.) I downloaded that input file through Sell Hub, manually.

3.) I uploaded that same file programmatically and it shows me BUF.Error.3...

I don't know if uploading a file somehow messes up the headers or body of the request.

If you want I can provide you how does an HTTP request look like when it is sending a file. Maybe the request is bad.

I don't know what to think next... 

[shipscript]

@overnightcomputer 

To clarify: you create a file on your desktop and upload manually through Seller Hub, and then take that same desktop file and place it on your server to upload programmatically to the Sandbox?  Was this intended to be a programmatic upload to Seller Hub or to one of the other APIs?

I'm speculating the same as you, that the programmatic upload is somehow corrupting the file. You might want to look at the fetch and send process.  Or, you may be using a wrong request. However, I don't have experience with that aspect.  Sorry to be no help there.

If this is a programmatic upload to seller hub, perhaps tools_apps_team@ebay can respond.

[overnightcomputer]

@shipscript 

It is intended to be a programmatic upload using Feed API.

Look what I found which is really, really weird....

If the uploaded file is corrupted, we could get that corrupted file back using the getInputFile method ?

Then what I tried is:

1) Uploaded a file (programmatically) that we assume will be corrupted, as every other file.

2) I used getInputFile to retrieve that same file (programmatically).

3) Went to second account and uploaded that "corrupted" file in Seller Hub (manually), and it works... Without any errors ???

So my assumption is that the files I'm sending aren't corrupted....

[overnightcomputer]

Denoting solution:

BAF.Error.3 shows in SANDBOX environment, but not in PRODUCTION.

That was the only option left to try. I didn't find solution to fix it in SANDBOX but someone might find this information useful.