Office.context.mailbox.item.addFileAttachmentAsync is taking too long to return response












1















I have been experiencing very inconsistent behavior with this call. Sometimes it succeeds, sometimes fails, but always takes a long time with the Outlook Web client.



We have seen this in dev, on production, with IE and Chrome browsers. Outlook is not affected. The back-end is Exchange 2016.



I pass the parameters (in my case it is url is query string that has filepath, filename and some other variables) to Office.context.mailbox.item.addFileAttachmentAsync. It triggers GET request and it goes ahead and reads file to stream in no time.



I looked into iis logs and looks like these GET requests are pretty quick, under 2 seconds. (time-taken value for each call is highlihted)



In Fiddler, we see the request that gets triggered by the Outlook API is: POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the GUID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"



Although the response returns quickly, the callback is not called promptly.



We have to add one attachment at a time, and it takes up to a minute before the first callback returns, so we can then make the call to add the next attachment. Often the callback returns with an error.



When it returns with an error, we've seen two different kinds of errors:




  • asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError"

  • asyncError: error: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"










share|improve this question

























  • How big is your attachment? File reading is a time-consuming operation. Because it is an operation on disk, not memory.

    – Bruce
    Nov 13 '18 at 10:05











  • they are less than 1mb

    – Namig Ismayilov
    Nov 13 '18 at 13:21











  • You stated your environment is by testing in Chrome. To verify, are you testing this add-in in Outlook on the Web? Are you using the new OWA beta when seeing this behavior? What is the size of the attachment you are adding?

    – Outlook Add-ins Team - MSFT
    Nov 13 '18 at 17:36













  • Outlook is not affected (Outlook directly requests the attachment URL). In OWA (IE or Chrome): POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the ID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"

    – Brian Clink
    Nov 22 '18 at 20:43











  • Browser just sits there for awhile and then reports an error. We've see two different error messages: asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError" asyncError: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"

    – Brian Clink
    Nov 22 '18 at 20:43
















1















I have been experiencing very inconsistent behavior with this call. Sometimes it succeeds, sometimes fails, but always takes a long time with the Outlook Web client.



We have seen this in dev, on production, with IE and Chrome browsers. Outlook is not affected. The back-end is Exchange 2016.



I pass the parameters (in my case it is url is query string that has filepath, filename and some other variables) to Office.context.mailbox.item.addFileAttachmentAsync. It triggers GET request and it goes ahead and reads file to stream in no time.



I looked into iis logs and looks like these GET requests are pretty quick, under 2 seconds. (time-taken value for each call is highlihted)



In Fiddler, we see the request that gets triggered by the Outlook API is: POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the GUID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"



Although the response returns quickly, the callback is not called promptly.



We have to add one attachment at a time, and it takes up to a minute before the first callback returns, so we can then make the call to add the next attachment. Often the callback returns with an error.



When it returns with an error, we've seen two different kinds of errors:




  • asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError"

  • asyncError: error: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"










share|improve this question

























  • How big is your attachment? File reading is a time-consuming operation. Because it is an operation on disk, not memory.

    – Bruce
    Nov 13 '18 at 10:05











  • they are less than 1mb

    – Namig Ismayilov
    Nov 13 '18 at 13:21











  • You stated your environment is by testing in Chrome. To verify, are you testing this add-in in Outlook on the Web? Are you using the new OWA beta when seeing this behavior? What is the size of the attachment you are adding?

    – Outlook Add-ins Team - MSFT
    Nov 13 '18 at 17:36













  • Outlook is not affected (Outlook directly requests the attachment URL). In OWA (IE or Chrome): POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the ID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"

    – Brian Clink
    Nov 22 '18 at 20:43











  • Browser just sits there for awhile and then reports an error. We've see two different error messages: asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError" asyncError: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"

    – Brian Clink
    Nov 22 '18 at 20:43














1












1








1


1






I have been experiencing very inconsistent behavior with this call. Sometimes it succeeds, sometimes fails, but always takes a long time with the Outlook Web client.



We have seen this in dev, on production, with IE and Chrome browsers. Outlook is not affected. The back-end is Exchange 2016.



I pass the parameters (in my case it is url is query string that has filepath, filename and some other variables) to Office.context.mailbox.item.addFileAttachmentAsync. It triggers GET request and it goes ahead and reads file to stream in no time.



I looked into iis logs and looks like these GET requests are pretty quick, under 2 seconds. (time-taken value for each call is highlihted)



In Fiddler, we see the request that gets triggered by the Outlook API is: POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the GUID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"



Although the response returns quickly, the callback is not called promptly.



We have to add one attachment at a time, and it takes up to a minute before the first callback returns, so we can then make the call to add the next attachment. Often the callback returns with an error.



When it returns with an error, we've seen two different kinds of errors:




  • asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError"

  • asyncError: error: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"










share|improve this question
















I have been experiencing very inconsistent behavior with this call. Sometimes it succeeds, sometimes fails, but always takes a long time with the Outlook Web client.



We have seen this in dev, on production, with IE and Chrome browsers. Outlook is not affected. The back-end is Exchange 2016.



I pass the parameters (in my case it is url is query string that has filepath, filename and some other variables) to Office.context.mailbox.item.addFileAttachmentAsync. It triggers GET request and it goes ahead and reads file to stream in no time.



I looked into iis logs and looks like these GET requests are pretty quick, under 2 seconds. (time-taken value for each call is highlihted)



In Fiddler, we see the request that gets triggered by the Outlook API is: POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the GUID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"



Although the response returns quickly, the callback is not called promptly.



We have to add one attachment at a time, and it takes up to a minute before the first callback returns, so we can then make the call to add the next attachment. Often the callback returns with an error.



When it returns with an error, we've seen two different kinds of errors:




  • asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError"

  • asyncError: error: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"







office-js outlook-web-addins office365-apps






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 27 '18 at 15:51









Brian Clink

1218




1218










asked Nov 12 '18 at 21:17









Namig IsmayilovNamig Ismayilov

2110




2110













  • How big is your attachment? File reading is a time-consuming operation. Because it is an operation on disk, not memory.

    – Bruce
    Nov 13 '18 at 10:05











  • they are less than 1mb

    – Namig Ismayilov
    Nov 13 '18 at 13:21











  • You stated your environment is by testing in Chrome. To verify, are you testing this add-in in Outlook on the Web? Are you using the new OWA beta when seeing this behavior? What is the size of the attachment you are adding?

    – Outlook Add-ins Team - MSFT
    Nov 13 '18 at 17:36













  • Outlook is not affected (Outlook directly requests the attachment URL). In OWA (IE or Chrome): POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the ID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"

    – Brian Clink
    Nov 22 '18 at 20:43











  • Browser just sits there for awhile and then reports an error. We've see two different error messages: asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError" asyncError: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"

    – Brian Clink
    Nov 22 '18 at 20:43



















  • How big is your attachment? File reading is a time-consuming operation. Because it is an operation on disk, not memory.

    – Bruce
    Nov 13 '18 at 10:05











  • they are less than 1mb

    – Namig Ismayilov
    Nov 13 '18 at 13:21











  • You stated your environment is by testing in Chrome. To verify, are you testing this add-in in Outlook on the Web? Are you using the new OWA beta when seeing this behavior? What is the size of the attachment you are adding?

    – Outlook Add-ins Team - MSFT
    Nov 13 '18 at 17:36













  • Outlook is not affected (Outlook directly requests the attachment URL). In OWA (IE or Chrome): POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the ID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"

    – Brian Clink
    Nov 22 '18 at 20:43











  • Browser just sits there for awhile and then reports an error. We've see two different error messages: asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError" asyncError: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"

    – Brian Clink
    Nov 22 '18 at 20:43

















How big is your attachment? File reading is a time-consuming operation. Because it is an operation on disk, not memory.

– Bruce
Nov 13 '18 at 10:05





How big is your attachment? File reading is a time-consuming operation. Because it is an operation on disk, not memory.

– Bruce
Nov 13 '18 at 10:05













they are less than 1mb

– Namig Ismayilov
Nov 13 '18 at 13:21





they are less than 1mb

– Namig Ismayilov
Nov 13 '18 at 13:21













You stated your environment is by testing in Chrome. To verify, are you testing this add-in in Outlook on the Web? Are you using the new OWA beta when seeing this behavior? What is the size of the attachment you are adding?

– Outlook Add-ins Team - MSFT
Nov 13 '18 at 17:36







You stated your environment is by testing in Chrome. To verify, are you testing this add-in in Outlook on the Web? Are you using the new OWA beta when seeing this behavior? What is the size of the attachment you are adding?

– Outlook Add-ins Team - MSFT
Nov 13 '18 at 17:36















Outlook is not affected (Outlook directly requests the attachment URL). In OWA (IE or Chrome): POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the ID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"

– Brian Clink
Nov 22 '18 at 20:43





Outlook is not affected (Outlook directly requests the attachment URL). In OWA (IE or Chrome): POST /owa/service.svc?action=CreateAttachmentFromUri&... In Fiddler, the response comes back right away, appears successful, it returns the ID: HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 X-OWA-Version: 15.1.1531.7 Content-Length: 38 "cd97a9c7-31e2-41b4-bf0d-39ac2450de39"

– Brian Clink
Nov 22 '18 at 20:43













Browser just sits there for awhile and then reports an error. We've see two different error messages: asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError" asyncError: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"

– Brian Clink
Nov 22 '18 at 20:43





Browser just sits there for awhile and then reports an error. We've see two different error messages: asyncResult: error: code:9002 message: "There was an internal format error." name: "InternalFormatError" asyncError: code: 9007 message: "The attachment cannot be added to the item." name: "AttachmentUploadGeneralFailure"

– Brian Clink
Nov 22 '18 at 20:43












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270251%2foffice-context-mailbox-item-addfileattachmentasync-is-taking-too-long-to-return%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270251%2foffice-context-mailbox-item-addfileattachmentasync-is-taking-too-long-to-return%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Full-time equivalent

Bicuculline

さくらももこ