Summary
I am seeing evidence that the Microsoft Graph OneDrive /delta API is not consistently returning deleted item tombstones after items have been successfully deleted from OneDrive.
This has been reproduced using two independent OneDrive clients against the same OneDrive Personal account:
-
Uploader client
- Creates folders and files.
- Uploads them to Microsoft OneDrive.
- Deletes the local folders/files.
- Sends delete requests to Microsoft OneDrive.
- Receives successful deletion responses.
-
Monitor / sync client
- Runs continuously in monitor mode.
- Receives remote change notifications.
- Fetches changes via Microsoft Graph
/delta.
- Processes
/delta responses to reconcile local state.
The uploader confirms that files and parent directories are successfully deleted from Microsoft OneDrive. However, the monitoring client does not receive corresponding /delta deleted item tombstones for some of those deleted items. In sustained test runs, the monitoring client retains stale folders/files locally even after completing a full sync cycle.
The behaviour strongly suggests that /delta is either:
- not returning deleted item tombstones for some deleted items; or
- returning previously deleted items as live objects without later returning corresponding delete tombstones.
Environment
Account type
OneDrive Personal
Microsoft data centre
Australia Southeast
Drive ID
5a0b9e159b3310ad
Client
Open-source OneDrive Client for Linux
Version observed during testing:
onedrive v2.5.10-52-g86a0da1
Transport
HTTP/1.1 forced due to known curl/libcurl HTTP/2 issues on the test platform.
Relevant client output
Application Version: onedrive v2.5.10-52-g86a0da1
Account Type: personal
Default Drive ID: 5a0b9e159b3310ad
Microsoft Data Centre: Australia Southeast
Downgrading all HTTP operations to HTTP/1.1 due to user configuration
Test setup
Two Linux systems are running against the same OneDrive account.
System A: uploader
This system repeatedly creates and deletes local content under:
~/OneDrive/random_files_upload
Each cycle creates:
10 directories
5 files per directory
50 files total
After a random delay, the uploader removes the contents of random_files_upload, which causes the client to delete the corresponding files and folders from Microsoft OneDrive.
System B: monitor / consumer
This system runs the OneDrive client in monitor mode and receives remote changes through Microsoft Graph /delta.
It is expected to maintain the same remote state as OneDrive.
Expected steady state under random_files_upload:
A detection script watches for sustained file drift. It only triggers after:
- file count exceeds 50;
- a subsequent full sync cycle completes;
- file count remains above 50 after that completed sync.
The detector watches for:
Sync with Microsoft OneDrive is complete
in the application log to avoid false positives during an in-progress reconciliation cycle.
Expected behaviour
When files and folders are deleted successfully from Microsoft OneDrive, subsequent Microsoft Graph /delta responses should include deleted item tombstones for those items.
Expected deleted item representation:
{
"id": "<item-id>",
"deleted": {}
}
or equivalent deleted item metadata as documented for OneDrive delta queries.
The monitoring client should then process those deleted item tombstones and remove the corresponding local files/directories and database entries.
Actual behaviour
The uploader successfully deletes the files and parent directories from Microsoft OneDrive.
Example uploader-side log for one affected directory:
[M] Local item deleted: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file2.data
The operating system sent a deletion notification. Trying to delete this item as requested: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file2.data
Deleting item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file2.data
Successfully deleted item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file2.data
[M] Local item deleted: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file0.data
The operating system sent a deletion notification. Trying to delete this item as requested: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file0.data
Deleting item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file0.data
Successfully deleted item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file0.data
[M] Local item deleted: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file4.data
The operating system sent a deletion notification. Trying to delete this item as requested: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file4.data
Deleting item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file4.data
Successfully deleted item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file4.data
[M] Local item deleted: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file1.data
The operating system sent a deletion notification. Trying to delete this item as requested: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file1.data
Deleting item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file1.data
Successfully deleted item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file1.data
[M] Local item deleted: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file3.data
The operating system sent a deletion notification. Trying to delete this item as requested: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file3.data
Deleting item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file3.data
Successfully deleted item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88/file3.data
[M] Local item deleted: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88
The operating system sent a deletion notification. Trying to delete this item as requested: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88
Deleting item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88
Successfully deleted item from Microsoft OneDrive: random_files_upload/0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88
This proves that:
local delete detected
delete request sent to Microsoft OneDrive
Microsoft OneDrive accepted the delete
However, the monitoring client does not receive corresponding deleted item tombstones via /delta for the affected items. The stale items remain locally after a completed sync cycle.
Sustained drift reproduction
A detector observed a drift condition at:
Tue 16 Jun 2026 16:54:03 AEST
At that point:
Directory Count: 20
File Count: 66
Expected Files: 50
Sync Complete #: 12
The detector then waited for the next completed sync cycle.
At:
Tue 16 Jun 2026 16:54:13 AEST
a subsequent completed sync was observed:
At that point the local state was still:
Directory Count: 20
File Count: 100
Expected Files: 50
The client was then gracefully terminated. It exited cleanly after two seconds.
Post-shutdown state remained:
Directory Count: 20
File Count: 100
This is important because it rules out a transient mid-sync state. The stale content persisted after:
- the drift was first observed;
- an additional full sync completed;
- the client performed a graceful shutdown.
Drift detector output
=================================================================
FILE DRIFT OBSERVED - WAITING FOR NEXT COMPLETED SYNC
Timestamp: Tue 16 Jun 2026 16:54:03 AEST
Directory Count: 20
File Count: 66
Expected Files: 50
Current Sync Complete #: 12
Watch Path: /home/alex/OneDrive/random_files_upload
Log File: /home/alex/onedrive.log
=================================================================
=================================================================
SUSTAINED FILE DRIFT DETECTED AFTER COMPLETED SYNC
Timestamp: Tue 16 Jun 2026 16:54:13 AEST
First Drift Observed: Tue 16 Jun 2026 16:54:03 AEST
Directory Count: 20
File Count: 100
Expected Files: 50
Sync Complete Baseline: 12
Current Sync Complete #: 13
Watch Path: /home/alex/OneDrive/random_files_upload
Capture ID: 20260616-165413
=================================================================
Pre-shutdown directory state:
0sOlRPSGNUdbVe4uVMVrctKvUNK7Kh88
2XN8DDEZZ89zJTwD7earMwVaenLWa6C0
5vnP7fXEkxBkEJvtTQ2XVlGkIpyyAR4a
6FsirFx3z5TzSjfMC6jQe61Gur7GNeip
6Lg8xLt11byTxKc14F1hbiu7TGbucVf1
arpfphLe4N2relvR17FGk28KUR0VoM08
B7vIKpTLfuSd8byGYpvohMPTYbFSi36m
BBcrsHZhEi70N9JouehqWMVKX3FG29hH
BwZWBEw1vJlTrh93DCYWgJNKO6YOfCQx
E9e4pPyr7CRIlblR30O3PNKcMyk0MBwB
FTqCx3IEMI0NbmAjFZYIx2Wvj1by1pNy
hlNsMQk3TRzzAjTOS7OBCpphbKcv5n0Z
HQTQNyZOWts1Ym6PMAMVAswLv4jMe2ZD
MetWJ7ioRsEXEDT1rFJMPc7cBuYqd0QF
pHDArDtgfb8BXgyR17Ru0XB4UELeI9Ai
RVyWp08SGC8OMTHlqbjWn4As71pQzjpr
T59J2GsDJsTneZ0MGepGeP7ZLHvZX6ib
tgXHmhxJfhNDhdz6fByxDIUhwcNMzzBL
W76f7TtUr2AQ49LVz3sGb9m5xdzk2m5y
wWFMeuC8xJ9gvtfY7A0TKa6KqMJVQSTU
Each of those directories contained five files:
5 files per directory
20 directories
100 files total
Expected state was:
Why this appears to be a /delta issue
The client-side deletion path has been instrumented to log successful remote deletion responses. The uploader confirms successful deletion of affected files and parent directories from Microsoft OneDrive.
The monitoring client then consumes /delta responses. For the affected items, the expected deleted item tombstones are not observed. Instead, the monitoring client either receives live item data or receives no deletion information sufficient to remove the stale local items.
The monitoring client completes synchronisation:
Sync with Microsoft OneDrive is complete
but stale content remains.
If /delta were returning the deleted tombstones, the client would process those tombstones and remove the local files/directories. The absence of those tombstones means the client has no authoritative deletion signal for the affected objects.
Why this does not appear to be a client-side delete failure
The uploader-side log shows successful delete acknowledgements from Microsoft OneDrive for files and parent directories.
Example pattern:
Deleting item from Microsoft OneDrive: random_files_upload/<directory>/fileN.data
Successfully deleted item from Microsoft OneDrive: random_files_upload/<directory>/fileN.data
Deleting item from Microsoft OneDrive: random_files_upload/<directory>
Successfully deleted item from Microsoft OneDrive: random_files_upload/<directory>
This is not merely a local delete notification. It confirms that the client invoked the OneDrive delete API and received success from Microsoft OneDrive.
Why this does not appear to be an interrupted sync
Early test attempts could be explained as transient in-progress reconciliation. To avoid that, the detector was changed to require sustained drift across a completed sync cycle.
The final reproduction confirms:
file drift observed
a subsequent "Sync with Microsoft OneDrive is complete" occurred
file drift still existed
client was gracefully terminated
file drift still existed after shutdown
Therefore, this is not simply an intermediate state while a delta batch was still being processed.
Impact
Applications relying on Microsoft Graph /delta to maintain a local mirror of OneDrive state can retain stale files/folders if deletion tombstones are omitted.
This causes local clients to believe deleted remote items still exist.
For sync engines, this can lead to:
- stale local files;
- stale local folder trees;
- local database drift;
- incorrect “sync complete” state;
- inability to reliably mirror remote deletions;
- possible data correctness issues for applications relying on
/delta as the authoritative change feed.
Request
Please investigate whether Microsoft Graph /delta for OneDrive Personal can omit deleted item tombstones under sustained create/delete churn.
Specifically:
- When a folder and its child files are successfully deleted via the OneDrive API, should
/delta always return deleted item tombstones for those objects?
- Is there any documented scenario where deleted child items or deleted parent folders may not appear in
/delta?
- Can
/delta return previously deleted items as live objects after the delete operation has succeeded?
- Are there known timing, batching, token, or eventual-consistency conditions where clients must perform a full enumeration to recover from missing delete tombstones?
- Is this behaviour expected for OneDrive Personal, or is this a service-side bug?
Minimal reproduction shape
A simplified reproduction is:
- Start with an empty folder:
-
Client A creates 10 folders under that path.
-
Client A creates 5 files in each folder.
-
Client A uploads all folders/files to OneDrive.
-
Client B consumes changes via /delta.
-
Client A deletes all 10 folders and their files.
-
Client A receives successful delete responses for each file and folder.
-
Client B continues consuming /delta.
-
Client B does not receive deleted tombstones for all deleted items.
-
Client B completes sync, but still has stale files/folders locally.
Observed sustained state:
Expected: 10 directories / 50 files
Actual: 20 directories / 100 files
The actual state represents one current generation plus one stale generation that should have been removed after the corresponding remote deletions.
Additional notes
This issue was reproduced using HTTP/1.1, not HTTP/2, to avoid known client-side or libcurl HTTP/2 instability.
The issue was observed against OneDrive Personal in the Australia Southeast Microsoft data centre.
The client application logs the full /delta responses in debug mode and can provide sanitised evidence if required. The available evidence currently indicates that the expected deleted item tombstones are absent from the /delta response for the affected stale items.
Summary
I am seeing evidence that the Microsoft Graph OneDrive
/deltaAPI is not consistently returning deleted item tombstones after items have been successfully deleted from OneDrive.This has been reproduced using two independent OneDrive clients against the same OneDrive Personal account:
Uploader client
Monitor / sync client
/delta./deltaresponses to reconcile local state.The uploader confirms that files and parent directories are successfully deleted from Microsoft OneDrive. However, the monitoring client does not receive corresponding
/deltadeleted item tombstones for some of those deleted items. In sustained test runs, the monitoring client retains stale folders/files locally even after completing a full sync cycle.The behaviour strongly suggests that
/deltais either:Environment
Account type
OneDrive Personal
Microsoft data centre
Australia Southeast
Drive ID
5a0b9e159b3310adClient
Open-source OneDrive Client for Linux
Version observed during testing:
onedrive v2.5.10-52-g86a0da1Transport
HTTP/1.1 forced due to known curl/libcurl HTTP/2 issues on the test platform.
Relevant client output
Test setup
Two Linux systems are running against the same OneDrive account.
System A: uploader
This system repeatedly creates and deletes local content under:
Each cycle creates:
After a random delay, the uploader removes the contents of
random_files_upload, which causes the client to delete the corresponding files and folders from Microsoft OneDrive.System B: monitor / consumer
This system runs the OneDrive client in monitor mode and receives remote changes through Microsoft Graph
/delta.It is expected to maintain the same remote state as OneDrive.
Expected steady state under
random_files_upload:A detection script watches for sustained file drift. It only triggers after:
The detector watches for:
in the application log to avoid false positives during an in-progress reconciliation cycle.
Expected behaviour
When files and folders are deleted successfully from Microsoft OneDrive, subsequent Microsoft Graph
/deltaresponses should include deleted item tombstones for those items.Expected deleted item representation:
{ "id": "<item-id>", "deleted": {} }or equivalent deleted item metadata as documented for OneDrive delta queries.
The monitoring client should then process those deleted item tombstones and remove the corresponding local files/directories and database entries.
Actual behaviour
The uploader successfully deletes the files and parent directories from Microsoft OneDrive.
Example uploader-side log for one affected directory:
This proves that:
However, the monitoring client does not receive corresponding deleted item tombstones via
/deltafor the affected items. The stale items remain locally after a completed sync cycle.Sustained drift reproduction
A detector observed a drift condition at:
At that point:
The detector then waited for the next completed sync cycle.
At:
a subsequent completed sync was observed:
At that point the local state was still:
The client was then gracefully terminated. It exited cleanly after two seconds.
Post-shutdown state remained:
This is important because it rules out a transient mid-sync state. The stale content persisted after:
Drift detector output
Pre-shutdown directory state:
Each of those directories contained five files:
Expected state was:
Why this appears to be a
/deltaissueThe client-side deletion path has been instrumented to log successful remote deletion responses. The uploader confirms successful deletion of affected files and parent directories from Microsoft OneDrive.
The monitoring client then consumes
/deltaresponses. For the affected items, the expected deleted item tombstones are not observed. Instead, the monitoring client either receives live item data or receives no deletion information sufficient to remove the stale local items.The monitoring client completes synchronisation:
but stale content remains.
If
/deltawere returning the deleted tombstones, the client would process those tombstones and remove the local files/directories. The absence of those tombstones means the client has no authoritative deletion signal for the affected objects.Why this does not appear to be a client-side delete failure
The uploader-side log shows successful delete acknowledgements from Microsoft OneDrive for files and parent directories.
Example pattern:
This is not merely a local delete notification. It confirms that the client invoked the OneDrive delete API and received success from Microsoft OneDrive.
Why this does not appear to be an interrupted sync
Early test attempts could be explained as transient in-progress reconciliation. To avoid that, the detector was changed to require sustained drift across a completed sync cycle.
The final reproduction confirms:
Therefore, this is not simply an intermediate state while a delta batch was still being processed.
Impact
Applications relying on Microsoft Graph
/deltato maintain a local mirror of OneDrive state can retain stale files/folders if deletion tombstones are omitted.This causes local clients to believe deleted remote items still exist.
For sync engines, this can lead to:
/deltaas the authoritative change feed.Request
Please investigate whether Microsoft Graph
/deltafor OneDrive Personal can omit deleted item tombstones under sustained create/delete churn.Specifically:
/deltaalways return deleted item tombstones for those objects?/delta?/deltareturn previously deleted items as live objects after the delete operation has succeeded?Minimal reproduction shape
A simplified reproduction is:
Client A creates 10 folders under that path.
Client A creates 5 files in each folder.
Client A uploads all folders/files to OneDrive.
Client B consumes changes via
/delta.Client A deletes all 10 folders and their files.
Client A receives successful delete responses for each file and folder.
Client B continues consuming
/delta.Client B does not receive deleted tombstones for all deleted items.
Client B completes sync, but still has stale files/folders locally.
Observed sustained state:
The actual state represents one current generation plus one stale generation that should have been removed after the corresponding remote deletions.
Additional notes
This issue was reproduced using HTTP/1.1, not HTTP/2, to avoid known client-side or libcurl HTTP/2 instability.
The issue was observed against OneDrive Personal in the Australia Southeast Microsoft data centre.
The client application logs the full
/deltaresponses in debug mode and can provide sanitised evidence if required. The available evidence currently indicates that the expected deleted item tombstones are absent from the/deltaresponse for the affected stale items.