“Software bugs are like cockroaches; there are probably dozens hiding in difficult to reach places for every one you find and fix.”
— Donald G. Firesmith
Last time, we went through the list of issues that have been reported so far, the biggest one being the fact that the REST API call to the Host instance is sending over the application logo image attachment instead of the Update Set XML file attachment. Since then, we have received some additional information in the form of the data logged to the REST API log file. Here is the entry of interest:
{
“size_bytes”: “547670”,
“file_name”: “logo”,
“sys_mod_count”: “0”,
“average_image_color”: “”,
“image_width”: “”,
“sys_updated_on”: “2022-08-02 16:55:55”,
“sys_tags”: “”,
“table_name”: “x_11556_col_store_member_application_version”,
“sys_id”: “c227acc297855110b40ebde3f153aff3”,
“image_height”: “”,
“sys_updated_by”: “csworker1.dev69362”,
“download_link”: “https://dev69362.service-now.com/api/now/attachment/c227acc297855110b40ebde3f153aff3/file”,
“content_type”: “image/jpeg”,
“sys_created_on”: “2022-08-02 16:55:55”,
“size_compressed”: “247152”,
“compressed”: “true”,
“state”: “pending”,
“table_sys_id”: “b127a88297855110b40ebde3f153afa6”,
“chunk_size_bytes”: “700000”,
“hash”: “8b5a07a6c0edf042df4b3c24e729036562985b705427ba7e33768566de94e96f”,
“sys_created_by”: “csworker1.dev69362”
}
If you look at the table_name property, you can see that it is attaching something to the version record, and if you look at the file_name and content_type properties, you can see that it isn’t the Update Set XML file that it is sending over. So let’s take a look at the shared code that sends over the Update Set XML file attachment and see if we can see where things may have gone wrong.
pushAttachment: function(attachmentGR, targetGR, remoteVerId) {
var result = {};
var gsa = new GlideSysAttachment();
result.url = 'https://';
result.url += targetGR.getDisplayValue('instance');
result.url += '.service-now.com/api/now/attachment/file?table_name=x_11556_col_store_member_application_version&table_sys_id=';
result.url += remoteVerId;
result.url += '&file_name=';
result.url += attachmentGR.getDisplayValue('file_name');
result.method = 'POST';
var request = new sn_ws.RESTMessageV2();
request.setEndpoint(result.url);
request.setHttpMethod(result.method);
request.setBasicAuth(this.WORKER_ROOT + targetGR.getDisplayValue('instance'), targetGR.getDisplayValue('token'));
request.setRequestHeader('Content-Type', attachmentGR.getDisplayValue('content_type'));
request.setRequestHeader('Accept', 'application/json');
request.setRequestBody(gsa.getContent(attachmentGR));
var response = request.execute();
result.status = response.getStatusCode();
result.body = response.getBody();
if (result.body) {
try {
result.obj = JSON.parse(result.body);
} catch (e) {
result.parse_error = e.toString();
}
}
result.error = response.haveError();
if (result.error) {
result.error_code = response.getErrorCode();
result.error_message = response.getErrorMessage();
}
this.logRESTCall(targetGR, result);
return result;
}
By this point in the process, the GlideRecord for the attachment has already been obtained from the database, so the problem has to be upstream from here. This is a shared function called from many places, but our problem is related to the application publishing process, so let’s take a look at the ApplicationPublisher Script Include and see if we can find where this function is called.
processPhase7: function(answer) {
var gsa = new GlideSysAttachment();
var attachmentGR = new GlideRecord('sys_attachment');
if (attachmentGR.get(answer.attachmentId)) {
var targetGR = this.getHostInstanceGR();
var csu = new CollaborationStoreUtils();
var result = csu.pushAttachment(attachmentGR, targetGR, answer.hostVerId);
if (result.error) {
answer = this.processError(answer, 'Error returned from Host instance: ' + result.error_code + ' - ' + result.error_message);
} else if (result.parse_error) {
answer = this.processError(answer, 'Unparsable JSON string returned from Host instance: ' + result.body);
} else if (result.status != 200 && result.status != 201) {
answer = this.processError(answer, 'Invalid HTTP Response Code returned from Host instance: ' + result.status);
} else {
answer.hostVerId = result.obj.result.sys_id;
}
} else {
answer = this.processError(answer, 'Invalid attachment record sys_id: ' + answer.attachmentId);
}
return answer;
}
Here we are fetching the attachment record based on the sys_id in the answer object property called attachmentId. There isn’t much opportunity for things to go tango uniform with this particular code, so I think we have to assume that somewhere upstream of this logic the value of answer.attachmentId got set to the sys_id of the logo attachment instead of the sys_id of the Update Set XML file attachment. So it looks like we need to do a quick search for answer.attachmentId and see where this property may have gotten corrupted.
Since the version record does not yet exist when the Update Set XML file is generated, it is initially attached to the stock application record. Then, once the version record has been created, the attachment is copied from the application record to the version record, and then the original attachment file is removed from the stock application record. All of that seems to work, since the Update Set XML file is, in fact, attached to the version record on the original source instance; however, somewhere along the line, the sys_id of that attachment record in the answer object ends up being the sys_id of the logo image attachment record. Let’s take a look at that code.
processPhase4: function(answer) {
var gsa = new GlideSysAttachment();
var values = gsa.copy('sys_app', answer.appSysId, 'x_11556_col_store_member_application_version', answer.versionId);
gsa.deleteAttachment(answer.attachmentId);
if (values.length > 0) {
var ids = values[values.length - 1].split(',');
if (ids[1]) {
answer.attachmentId = ids[1];
} else {
answer = this.processError(answer, 'Unrecognizable response from attachment copy: ' + JSON.stringify(values));
}
} else {
answer = this.processError(answer, 'Unrecognizable response from attachment copy: ' + JSON.stringify(values));
}
return answer;
}
This has to be the source of the problem. The copy method the GlideSysAttachment object doesn’t allow you to select what to copy; it arbitrarily copies all attachments from one record to another and returns an array of sys_id pairs (before and after for each attachment). The code above assumed that the last pair contained the sys_id that we were looking for, but apparently, that is not always the case. It looks like we need to examine every sys_id pair in the array, select the one that contains the XML file, grab that sys_id, and then delete all of the other attachments from the version record. That would mean replacing this:
var ids = values[values.length - 1].split(',');
if (ids[1]) {
answer.attachmentId = ids[1];
}
… with this:
var origId = answer.attachmentId;
for (var i=0; i<values.length; i++) {
var ids = values[i].split(',');
if (ids[0] == origId) {
answer.attachmentId = ids[1];
gsa.deleteAttachment(origId);
} else {
gsa.deleteAttachment(ids[1]);
}
}
Basically, this code loops through all of the sys_id pairs, looks for the one where the first sys_id matches the original, grabs the second sys_id of that pair for the new answer.attachmentId value, and then deletes the original attachment record. When the first sys_id does not match, then it deletes the copied attachment from the version record, as we did not want to copy that one anyway. We will have to do a little testing to prove this out, but hopefully this will resolve this issue.
Next time, we should have a new Update Set available with this, and a few other, minor corrections in it, and then we can do a little retesting and see if that resolves a few of these issues. As always, if anyone finds anything else that we need to address, please leave the details in the comments section below. All feedback is heartily welcomed!
