[Graph API Issue] Intermittent GenericFileOpenError causing missing data blocks when writing batched data to Excel workbooks

[garima-cloudextend]

Describe the bug
Our customers schedule automated data downloads that write batched data to Excel workbooks (OneDrive for Business / SharePoint) using the Microsoft Graph API. The API fails intermittently, resulting in missing blocks of data in the Excel sheet with either one of the below mentioned errors in our logs.
The pattern is: Data → Empty Block → Data → Empty Block → Data...
This is not a complete failure or cutoff - it's intermittent gaps throughout the file.

Errors Encountered
Error 1: GenericFileOpenError
{"error":{"code":"GenericFileOpenError","message":"The workbook cannot be opened.","innerError":{"code":"internalServerErrorUncategorized","message":"An unspecified error has occurred.","innerError":{"code":"GenericFileOpenError","message":"The workbook cannot be opened."},"date":"2026-04-20T10:48:41","request-id”:”sample-request-id","client-request-id”:”sample-client-request-id”}}}

Error 2: HTTP Timeout

HTTP callout did not complete within time limit

Previous Support Ticket
We raised a similar support ticket with the Microsoft team earlier. They recommended using workbook sessions. We implemented sessions with the Prefer: respond-async header as suggested, but we are still facing issues.

Our Implementation
API Operations Used:

• POST /drives/{driveId}/items/{itemId}/workbook/createSession (with Prefer: respond-async header)
• POST /drives/{driveId}/items/{itemId}/workbook/tables/{tableId}/rows/add (with workbook-session-id header)
• POST /drives/{driveId}/items/{itemId}/workbook/closeSession

Request Body for rows/add:

{
  "values": [
    ["row1col1", "row1col2", "row1col3", ...],
    ["row2col1", "row2col2", "row2col3", ...],
    ...
  ]
}

Flow:

1. Fetch data from external system in batches (pages of rows)
2. Write each batch sequentially to Excel table using rows/add
3. Batches are written one at a time (not parallel)

Testing Results with Sessions
Even after implementing sessions as recommended, the results were inconsistent:

Test Scenario	Result
Plain file with empty table	Writes successfully
File with existing data	Clears and writes properly
File open in desktop Excel during scheduled write	Overwrites content with scheduled data (Expected)
File open by multiple users on different sheets	Graph API writes successfully
File open by multiple users on same sheet	Clears data but doesn't write back (Excel file locking)
Large data with smaller page sizes (20, 50 rows)	Occasionally empty blocks appear, but we didn't always get corresponding errors
5 simultaneous flows to 5 different workbooks (Run 1)	4/5 succeeded, but 1 flow failed with "invalid session" errors - only 500 rows written out of ~10,000 (193/205 pages failed)
5 simultaneous flows to 5 different workbooks (Run 2)	All 5 flows ran successfully with 0 errors
Multiple flows to same workbook	Similar inconsistent results

Key Observations:

1. Empty data blocks appear in Excel without corresponding errors being returned by the API
2. Sessions become invalid mid-operation ("invalid session" error) with no clear cause
3. Same operation succeeds sometimes, fails other times - behavior is non-deterministic
4. No data discrepancies when writes succeed - the issue is writes failing silently or with intermittent errors

Logs from Previous Testing
We can share logs over email if required.

Questions

1. What causes GenericFileOpenError with internalServerErrorUncategorized? Is this a transient server-side issue? Why does it happen intermittently?
2. If we do not use sessions, we can see GenericFileOpenErrors multiple times in same scheduled download sheet, how can we fix this as even after using sessions , the issue of missing blocks of data still persists without any explicit errors from graph api?
3. Why do sessions become invalid mid-operation? We create a session, use it for sequential writes, but it becomes invalid partway through.
4. Why do some writes fail silently when sessions are used? Empty blocks appear in Excel but no error is returned by the API - this makes retry logic impossible.

To Reproduce
Steps to reproduce the behavior:

Without Sessions:

1. Write multiple batches of data sequentially using POST /drives/{driveId}/items/{itemId}/workbook/tables/{tableId}/rows/add
2. Each batch contains 1000-5000 rows of data
3. Repeat for 50-200+ batches (to write 50,000-100,000+ rows total)
4. Some batches intermittently fail with GenericFileOpenError or HTTP callout did not complete within time limit
5. Result: Excel table has missing blocks of data (pattern: Data → Empty → Data → Empty)

With Sessions (as recommended by Microsoft support):

1. Create a workbook session using POST /drives/{driveId}/items/{itemId}/workbook/createSession with Prefer: respond-async header and {"persistChanges": true} body
2. Write multiple batches of data sequentially using POST /drives/{driveId}/items/{itemId}/workbook/tables/{tableId}/rows/add with the workbook-session-id header
3. Each batch contains 1000-5000 rows of data
4. Repeat for 50-200+ batches
5. Same intermittent failures occur - additionally, sessions sometimes become invalid mid-operation with "invalid session" error
6. Result: Same missing blocks of data in Excel table

The issue occurs in both approaches.

Expected behavior
All API calls should either:

1. Return success (200/201) and persist the data to the Excel table, OR
2. Return a clear error response that can be used to implement retry logic

Currently, some calls fail silently (no error returned, but data is not written), and some fail with GenericFileOpenError which provides no actionable information.

Impact
This is a high-impact production issue affecting paying customers. Users schedule automated data exports and discover hours later that their Excel files have missing rows of data, with no clear indication of failure in our system logs.
We need guidance on how to reliably write large batched data to Excel tables using rows/add without intermittent failures. Could you please assist us in resolving this issue as soon as possible.
Thank you for your assistance.