onMessageSend add-in completes successfully but email with SharePoint cloud attachment drops to Drafts with "attachments failed to upload" in New Outlook for Windows — occurs frequently in Reply/Forward

Ashish Pal 0 Reputation points
2026-07-22T10:39:46.72+00:00

Summary

I have an Outlook add-in that classifies emails on send by injecting a classification banner (header and footer) into the message body via body.getAsync / body.setAsync during the onMessageSend event. The add-in does not interact with attachments in any way.

We are observing that when a user replies to or forwards an email thread that contains a SharePoint Online cloud attachment — particularly where the sender does not yet have access to the SharePoint file — Outlook fails to send the email after the add-in completes successfully and drops it to Drafts with the error "one or more attachments failed to upload." The add-in receives no error at any point. The issue does not occur consistently on new mail and is not reproducible for all users — only specific users on specific mail threads. Console logs show odbsharelightspeed failing to acquire an authToken and a subsequent CORS failure on attachments.office.net exclusively in the failing case, with no such errors in successful sends.

Your Environment

  • Platform: New Outlook for Windows (OneOutlook)
  • Host: Outlook
  • Office version number: 1.2026.609.400
  • Operating System: Windows 11
  • Browser (if using Office on the web): N/A — issue occurs in New Outlook for Windows, not in browser

Expected behavior

When an onMessageSend add-in completes successfully and calls event.completed({ allowEvent: true }), the email should be sent with the cloud attachment (SharePoint Online link) intact and recipients should be granted access to the shared file.

Current behavior

After the add-in completes without any errors, Outlook fails to send the email and saves it to Drafts with the native error: "There was a problem sending this message because one or more attachments failed to upload. Please try again." The failure occurs in Outlook's own cloud-attachment finalization step — after the add-in has already handed control back via event.completed({ allowEvent: true }). No error is surfaced to the add-in at any point. This issue occurs most frequently in reply/forward scenarios where the add-in classifies a previously unclassified email when the user replies to or forwards it. It does not occur consistently on new mail composition. It is also specific to certain users and mail threads, not all users or all emails for the affected user.

Steps to reproduce

  1. In New Outlook for Windows, open an existing email thread and hit Reply or Forward.
  2. The replied/forwarded email contains a SharePoint Online cloud attachment (a .pptx or similar file shared as a link chip in the body). The sending user does not yet have access to the SharePoint file being attached.
  3. Register an add-in for the onMessageSend event that does the following:
    • Reads the current body via body.getAsync
      • Adds a text banner (header and footer) to the body HTML without modifying any existing content
        • Writes the modified body back via body.setAsync
          • Calls event.completed({ allowEvent: true })
          1. Hit Send.
          2. Observe the error banner and the message landing in Drafts. Note: The same flow on a new mail composition does not reproduce the issue consistently. The add-in explicitly skips cloud attachments — it does not read, scan, upload, or modify them.

Provide additional details

  1. The add-in completes fully without errors — all Office.js async calls return AsyncResultStatus.Succeeded.
  2. No add-in-related errors appear in the console in either the failing or succeeding case.
  3. The only discriminating errors between a failing send and a successful send are the odbsharelightspeed and attachments.office.net entries listed under Useful Logs below — these are completely absent in successful sends.
  4. The issue does not reproduce for all users — only specific users with specific mail threads where the sender does not have access to the attached SharePoint file.
  5. The issue happens most frequently in reply/forward cases where the add-in classifies a previously unclassified mail when the user replies to or forwards it.

Your Environment

  • Platform: New Outlook for Windows (OneOutlook)
  • Host: Outlook
  • Office version number: 1.2026.609.400
  • Operating System: Windows 11
  • Browser (if using Office on the web): N/A — issue occurs in New Outlook for Windows, not in browser

Expected behavior

When an onMessageSend add-in completes successfully and calls event.completed({ allowEvent: true }),
the email should be sent with the cloud attachment (SharePoint Online link) intact and recipients
should be granted access to the shared file.

Current behavior

After the add-in completes without any errors, Outlook fails to send the email and saves it to
Drafts with the native error:
"There was a problem sending this message because one or more attachments failed to upload.
Please try again."
The failure occurs in Outlook's own cloud-attachment finalization step — after the add-in has
already handed control back via event.completed({ allowEvent: true }). No error is surfaced to
the add-in at any point.
This issue occurs most frequently in reply/forward scenarios where the add-in classifies a
previously unclassified email when the user replies to or forwards it. It does not occur
consistently on new mail composition. It is also specific to certain users and mail threads,
not all users or all emails for the affected user.

Steps to reproduce

  1. In New Outlook for Windows, open an existing email thread and hit Reply or Forward.
  2. The replied/forwarded email contains a SharePoint Online cloud attachment (a .pptx or
    similar file shared as a link chip in the body). The sending user does not yet have
    access to the SharePoint file being attached.
  3. Register an add-in for the onMessageSend event that does the following:
    • Reads the current body via body.getAsync
    • Adds a text banner (header and footer) to the body HTML without modifying any
      existing content
    • Writes the modified body back via body.setAsync
    • Calls event.completed({ allowEvent: true })
  4. Hit Send.
  5. Observe the error banner and the message landing in Drafts.
    Note: The same flow on a new mail composition does not reproduce the issue consistently.
    The add-in explicitly skips cloud attachments — it does not read, scan, upload, or modify them.

Provide additional details

  1. The add-in completes fully without errors — all Office.js async calls return
    AsyncResultStatus.Succeeded.
  2. No add-in-related errors appear in the console in either the failing or succeeding case.
  3. The only discriminating errors between a failing send and a successful send are the
    odbsharelightspeed and attachments.office.net entries listed under Useful Logs below —
    these are completely absent in successful sends.
  4. The issue does not reproduce for all users — only specific users with specific mail
    threads where the sender does not have access to the attached SharePoint file.

Usefull logs

  1. > The issue happens most frequently in reply/forward cases where the add-in classifies  
  > a previously unclassified mail when the user replies to or forwards it.![614544236-e3e8016c-3761-44cf-a16c-c1e4a2a06578](/api/attachments/eaa7e538-43de-4e6c-a9d3-901e1cc27529?platform=QnA)
  > 
  > ![614548283-3ef28867-fd69-4e24-adcd-2e0870694767](/api/attachments/20809a20-9203-45b8-9633-c7734d502876?platform=QnA)
  > 
  > ![614548611-22f89006-4ebc-4566-816b-287fccb195c9 (1)](/api/attachments/9e085f48-1a99-40a9-a89e-fae2fae7efeb?platform=QnA)
  
  Uncaught TypeError: Cannot read properties of undefined (reading 'authToken')
  
      odbsharelightspeed.js:72
  
  Uncaught TypeError: Cannot read properties of undefined (reading 'authToken')
  
      odbsharelightspeed.js:72
  
  Access to fetch at
  
  'https://attachments.office.net/owa/test.m%test.com/service.svc/s/G…
  
  origin=6&animation=true&persistenceId=d0848656-3b9d-49be-88e3-8f237eef0688'
  
  from origin 'https://outlook.office.com' has been blocked by CORS policy:
  
  No 'Access-Control-Allow-Origin' header is present on the requested resource.
  
    
  The FetchEvent for 'https://attachments.office.net/owa/…persistenceId=d0848656…'
  
  resulted in a network error response: the promise was rejected.
Microsoft 365 and Office | Development | Office JavaScript API
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Michelle-N 20,735 Reputation points Microsoft External Staff Moderator
    2026-07-22T11:31:32.5533333+00:00

    Hi @Ashish Pal

    Based on your description, this does not look like a failure in your onMessageSend handler itself. The key point is that your add-in completes successfully, all Office.js calls return AsyncResultStatus.Succeeded, and the failure happens only after event.completed({`` ``allowEvent:`` ``true`` ``}), during Outlook’s native cloud-attachment finalization flow.

    From the information available, the most reasonable interpretation is that the add-in may be triggering or exposing a timing/state issue in New Outlook’s send pipeline, but the actual error appears to occur in Outlook’s own attachment or cloud-link handling path. In particular, the odbsharelightspeed.js authToken failure and the attachments.office.net CORS error are not errors returned by your add-in APIs.

    Please refer the following workarounds:

    1. Immediate technical workarounds (try in this order)

    -Prefer body.prependAsync (header) + body.appendAsync (footer) instead of full get + set

    -Use item.saveAsync() before calling event.completed

    -Minimize HTML changes (avoid rewriting large parts of the body)

    -Fall back to subject prefix only when cloud attachments are present

    Example of safer body modification pattern:

    function onMessageSendHandler(event) {
  Office.context.mailbox.item.getAttachmentsAsync((result) => {
    const hasCloudAttachment = result.value?.some(att => 
      att.attachmentType === "cloud" || att.isInline === false && att.name?.includes(".sharepoint")
    );
 
    if (hasCloudAttachment) {
      // Safer path – only touch subject or use prepend/append carefully
      // or skip classification for now
      event.completed({ allowEvent: true });
      return;
    }
 
    // Normal path with prepend/append
    Office.context.mailbox.item.body.prependAsync(
      "<div>...classification header...</div>",
      { coercionType: Office.CoercionType.Html },
      () => {
        Office.context.mailbox.item.body.appendAsync(
          "<div>...classification footer...</div>",
          { coercionType: Office.CoercionType.Html },
          () => event.completed({ allowEvent: true })
        );
      }
    );
  });
}
    1. Longer-term / architectural options
    • Move classification to Sensitivity Labels (Purview) if the requirement is compliance-related — these integrate much better with the send pipeline and handle cloud attachments correctly.
    • Use a SoftBlock Smart Alert that shows a dialog and lets the user confirm, instead of silently modifying the body on every send.
    • For high-impact classification scenarios, consider a combination of OnNewMessageCompose + OnMessageFromChanged + a final SoftBlock check.

    I hope this information help.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.