3 Replies Latest reply on Feb 16, 2018 1:30 PM by Sanford Whiteman

    Bulk Export File Download Errors - suggestion and question

    Kurt Koller

      Currently, when you download a file on the Bulk API at  and there is a server problem on the Marketo env, instead of the CSV file you get

       

      {"requestId":"3fd2#161992bc7e1","success":false,"errors":[{"code":"611","message":"System error"}]}

       

      It would be ideal if this call would return a 500 or 503 status code, since this is a file retrieval operation and not an API call like the others.

       

      We can check length of the download as a bandaid, but if we are getting leads and we get just a header row it could easily end up being the same length as the specified file download length. And it's a little awkward to check what's supposed to be a CSV export file for json.

       

       

      ALSO

       

      When you're out of quota you get an error 1029.

       

      http://developers.marketo.com/rest-api/bulk-extract/

       

      "The daily quota is a maximum of 500MB per day, which is shared between leads and activities.  When the quota is exceeded, you cannot Create or Enqueue another job until the daily quota resets at midnight Central Time.  Until that time, an error “1029, Export daily quota exceeded” is returned."

       

      The error message in the table of errors http://developers.marketo.com/rest-api/error-codes/  says:

       

      1029Too many jobs in queueSubscriptions are allowed a maximum of 10 bulk extract jobs in the queue at any given time.

       

      Is this error doubled up on or is the documentation incorrect?

       

       

      Thanks,

       

      Kurt

        • Re: Bulk Export File Download Errors - suggestions
          Sanford Whiteman

          Does it not set the Content-Type in this case? I agree, conditionally parsing the first N chars as JSON is inelegant, but should be accurate at least.

            • Re: Bulk Export File Download Errors - suggestion and question
              Kurt Koller

              Well, this was a transient error and I have no way of generating this on command that I can think of, so I can't tell you what the headers looked like. I just had a file that downloaded correctly, wouldn't import, and it had json in it. I can put in a check for the file length (wasn't in there because if the file downloaded correctly with no errors and a 200 status code I'd assume that was a success). Ideally a REST API would set the HTTP result code so you can logic accordingly (i.e. 5xx is a server side problem, you can try that one again later, 4xx is a client problem so you can log that and figure out what you (the client) did wrong, etc) before getting into results / file contents.

               

              They return a 4xx code when you try to get something without credentials, so this type of code would work for instance (we have something like it in production), however the last bit doesn't catch the error in question because they return a success HTTP code:

               

              ```

              if (response.IsSuccessStatusCode)

              {

                        // read file            

                        return true;

              }

              else

              {

                                      if (response.StatusCode == HttpStatusCode.Forbidden)

                                          throw new AuthenticationException("Invalid username/password combination.");

                                      else

                                          throw new Exception($"Bulk download error, API returned http status {response.StatusCode}");

              }

              ```

               

              I could check json and content types sure but this is the correct way for a REST API to report errors, and the Marketo API does return a forbidden when you haven't authenticated or your token has expired, so I think they should continue that through to the rest of the API error codes, particularly on this url where we aren't needing/wanting to parse the result at the time of download.

                • Re: Bulk Export File Download Errors - suggestion and question
                  Sanford Whiteman

                  Oh, I absolutely agree that a failure response to the file.json request should be via HTTP 5xx! But we don't have that ideal world.

                   

                  The HTTP 200 w/embedded 611 is obviously bad and undocumented but nevertheless may happen again. And in such a case, as far as I know, the origin (download server) doesn't get involved. So you can check the Content-Type (there may not be a Content-Type at all, so I would check for is not */csv as opposed to is application/json).

                   

                  (Some documented falsy responses in the Bulk Extract sequence, like status.json, are embedded in HTTP 200 instead of, say, HTTP 503 w/retry-after... like almost every service it's RESTish but not pedantically RESTful.)