I noticed that when I do a batch update and one of the records fails to update, the result file contains "null" for the id.  However when the update is successful, the id is populated.  Is this a bug?  Why wouldn't the erroneous record also include an id?  Below is a snippet of the json result:

{
success: true,
created: false,
id: "00Q6000001MdNFAEA3",
errors: [ ]
},
{
success: false,
created: false,
id: null,
errors: [
{
message: "First Name: data value too large: SUPER_LONG_STRING_WAS_HERE= (max length=40)",
fields: [
"FirstName"
],
statusCode: "STRING_TOO_LONG",
extendedErrorDetails: null
}
]
}

Occasionally, when I attempt to retrieve BatchResults for a bulk API Job it returns an invalid json response. This frequently happens for batches with  "TooManyLockFailure : Too many lock failure 200 Trying again later" error messages. I'm trying to use the BatchResults to determine which updates to retry.

The responses are missing a comma in the middle of the error messages.  It appears that when the error message list is large, it is not serialized to json correctly. Below is a snippet of the response around one of the invalid json responses. 

{
"success" : false,
"created" : false,
"id" : null,
"errors" : [ {
"message" : "unable to obtain exclusive access to this record or 200 records: 00Q6000001L1DEUEA3,00Q6000001L1DEVEA3,00Q6000001L1DEWEA3,00Q6000001L1DEXEA3,00Q6000001L1DEYEA3,00Q6000001L1DEZEA3,00Q6000001L1DDpEAN,00Q6000001L1DF2EAN,00Q6000001L1DF3EAN,00Q6000001L1DF4EAN,00Q6000001L1DF5EAN,00Q6000001L1DF6EAN,00Q6000001L1DF7EAN,00Q6000001L1DF8EAN,00Q6000001L1DF9EAN,00Q6000001L1DD3EAN,00Q6000001L1DD4EAN,00Q6000001L1DDsEAN,00Q6000001L1DDuEAN,00Q6000001L1DDwEAN,00Q6000001L1DEQEA3,00Q6000001L1DEREA3,00Q6000001L1DGZEA3,00Q6000001L1DGaEAN,00Q6000001L1DGbEAN,00Q6000001L1DGdEAN,00Q6000001L1DGeEAN,00Q6000001L1DHAEA3,00Q6000001L1DHBEA3,00Q6000001L1DHCEA3,00Q6000001L1DHDEA3,00Q6000001L1DHEEA3,00Q6000001L1DHFEA3,00Q6000001L1DIbEAN,00Q6000001L1DIcEAN,00Q6000001L1DIeEAN,00Q6000001L1DIfEAN,00Q6000001L1DIgEAN,00Q6000001L1DIiEAN,00Q6000001L1DIjEAN,00Q6000001L1DIkEAN,00Q6000001L1DIlEAN,00Q6000001L1DJCEA3,00Q6000001L1DJDEA3,00Q6000001L1DJEEA3,00Q6000001L1DJFEA3,00Q6000001L1DJGEA3,00Q6000001L1DJHEA3,00Q6000001L1DJIEA3,00Q6000001L1DKkEAN,00Q6000001L1DKlEAN,00Q6000001L1DKmEAN,00Q6000001L1DKoEAN,00Q6000001L1DKpEAN,00Q6000001L1DKqEAN,00Q6000001L1DKsEAN,00Q6000001L1DKuEAN,00Q6000001L1DLLEA3,00Q6000001L1DLMEA3,00Q6000001L1DLNEA3,00Q6000001L1DLOEA3,00Q6000001L1DLPEA3,00Q6000001L1DLQEA3,00Q6000001L1DLREA3,00Q6000001L1DLSEA3,00Q6000001L1DLTEA3,00Q6000001L1DLUEA3,00Q6000001L1DLVEA3,00Q6000001L1DM1EAN,00Q6000001L1DM3EAN,00Q6000001L1DM4EAN,00Q6000001L1DM5EAN,00Q6000001L1DM6EAN,00Q6000001L1DM7EAN,00Q6000001L1DQAEA3,00Q6000001L1DQBEA3,00Q6000001L1DQEEA3,00Q6000001L1DQFEA3,00Q6000001L1DQGEA3,00Q6000001L1DNVEA3,00Q6000001L1DNWEA3,00Q6000001L1DNXEA3,00Q6000001L1DO5EAN,00Q6000001L1DO6EAN,00Q6000001L1DO7EAN,00Q6000001L1DO8EAN,00Q6000001L1DO9EAN,00Q6000001L1DPaEAN,00Q6000001L1DPbEAN,00Q6000001L1DPcEAN,00Q6000001L1DPdEAN,00Q6000001L1DPeEAN,00Q6000001L1DPfEAN,00Q6000001L1DTmEAN,00Q6000001L1DTnEAN,00Q6000001L1DToEAN,00Q6000001L1DTpEAN,00Q6000001L1DTqEAN,00Q6000001L1DTrEAN,00Q6000001L1DTsEAN,00Q6000001L1DTtEAN,00Q6000001L1DTuEAN,00Q6000001L1DTvEAN,00Q6000001L1DTwEAN,00Q6000001L1DUNEA3,00Q6000001L1DUOEA3,00Q6000001L1DUPEA3,00Q6000001L1DUQEA3,00Q6000001L1DUREA3,00Q6000001L1DUSEA3,00Q6000001L1DUTEA3,00Q6000001L1DUVEA3,00Q6000001L1DUWEA3,00Q6000001L1DUXEA3,00Q6000001L1DV0EAN,00Q6000001L1DV2EAN,00Q6000001L1DV5EAN,00Q6000001L1DV6EAN,00Q6000001L1DV7EAN,00Q6000001L1DV8EAN,00Q6000001L1DV9EAN,00Q6000001L1DT0EAN,00Q6000001L1DT1EAN,00Q6000001L1DT2EAN,00Q6000001L1DaAEAV,00Q6000001L1DaBEAV,00Q6000001L1DaCEAV,00Q6000001L1DaDEAV,00Q6000001L1DYaEAN,00Q6000001L1DYbEAN,00Q6000001L1DYcEAN,00Q6000001L1DYdEAN,00Q6000001L1DYeEAN,00Q6000001L1DYfEAN,00Q6000001L1DYgEAN,00Q6000001L1DYhEAN,00Q6000001L1DYiEAN,00Q6000001L1DbcEAF,00Q6000001L1DbdEAF,00Q6000001L1DbeEAF,00Q6000001L1DbgEAF,00Q6000001L1DbhEAF,00Q6000001L1DbiEAF,00Q6000001L1DZAEA3,00Q6000001L1DZBEA3,00Q6000001L1DZCEA3,00Q6000001L1DZDEA3,00Q6000001L1DZEEA3,00Q6000001L1DZFEA3,00Q6000001L1DZGEA3,00Q6000001L1DZHEA3,00Q6000001L1DZIEA3,00Q6000001L1DZJEA3,00Q6000001L1DbjEAF,00Q6000001L1DjAEAV,00Q6000001L1DjBEAV,00Q6000001L1DjCEAV,00Q6000001L1DjDEAV,00Q6000001L1DjEEAV,00Q6000001L1DjFEAV,00Q6000001L1DjHEAV,00Q6000001L1DgSEAV,00Q6000001L1DgTEAV,00Q6000001L1DgUEAV,00Q6000001L1DgXEAV,00Q6000001L1DgYEAV,00Q6000001L1DgZEAV,00Q6000001L1Dh4EAF,00Q6000001L1Dh5EAF,00Q6000001L1Dh6EAF,00Q6000001L1Dh7EAF,00Q6000001L1Dh8EAF,00Q6000001L1Dh9EAF,00Q6000001L1DiaEAF,00Q6000001L1DibEAF,00Q6000001L1DicEAF,00Q6000001L1DidEAF,00Q6000001L1DieEAF,00Q6000001L1DigEAF,00Q6000001L1DouEAF,00Q6000001L1DovEAF,00Q6000001L1DowEAF,00Q6000001L1DoxEAF,00Q6000001L1DoyEAF,00Q6000001L1DozEAF,00Q6000001L1DpWEAV,00Q6000001L1DpXEAV,00Q6000001L1DpYEAV,00Q6000001L1DpZEAV,00Q6000001L1Dq7EAF,00Q6000001L1Dq8EAF,00Q6000001L1Dq9EAF,00Q6000001L1DqAEAV,00Q6000001L1Do0EAF,00Q6000001L1Do3EAF,00Q6000001L1Do4EAF,00Q6000001L1Do5EAF,00Q6000001L1Do6EAF,00Q6000001L1Do7EAF,00Q6000001L1Do8EAF",
"fields" : [ ],
"statusCode" : "UNABLE_TO_LOCK_ROW",
"extendedErrorDetails" : null
} ]
} { <------------------------- Comma missing here
"success" : true,
"created" : false, 
"id" : "00Q6000001L1E05EAF",
"errors" : [ ]
}...

the missing comma comes after a string of over one hundred such error messages. 

This invalid json makes the REST endpoint unusable in determining which records in a batch succeeded and which failed.

Has anyone else observed this issue?  If so, is salesforce planning to fix it or is there a work-around?

I noticed that when I do a batch update and one of the records fails to update, the result file contains "null" for the id.  However when the update is successful, the id is populated.  Is this a bug?  Why wouldn't the erroneous record also include an id?  Below is a snippet of the json result:

{
success: true,
created: false,
id: "00Q6000001MdNFAEA3",
errors: [ ]
},
{
success: false,
created: false,
id: null,
errors: [
{
message: "First Name: data value too large: SUPER_LONG_STRING_WAS_HERE= (max length=40)",
fields: [
"FirstName"
],
statusCode: "STRING_TOO_LONG",
extendedErrorDetails: null
}
]
}

When querying objects via the  Bulk API, timestamps and dates are returned as millis not strings.  This is inconsistent with other salesforce APIs.  For timestamps this is not necessarily a problem since the conversion is straight-forward and all timezones are UTC-based.  For dates, it is actively returning incorrect values.  Our organization's default timezone is CST and we've verified that our dates are being stored as dates in CST.  When the Bulk API returns millis, they are being returned as midnight UTC instead of midnight in our default time zone.  Realistically, it should not be returning millis and indicating any time zone opinion at all since there is no time zone information stored on a date type. Anyone have some insights into this?