Critical Bug Report: Transaction (requestId) duplicated. Server fails Idempotency check on 10 days apart syncs, causing data overwrite (Zombie Edit)

AppSheet AppSheet Q&A
, ,
1

Hello AppSheet Community and Support Team,

I need to report a severe data integrity issue involving a duplicate transaction that occurred 10 days after the original event, bypassing what I assume should be standard server-side de-duplication (idempotency) checks.

The Scenario:

  1. Original Event (Jan 9, 2026): A user performed an “Edit row” action.
  • Timestamp: 2026-01-09 T17:54:41 UTC
  • RequestId: 22795848
  • Audit Log Result: Success
  1. The Interim: For 10 days, the user did not apparently use the app or sync. During this time, other users modified the same row, advancing the workflow.
  2. The “Zombie” Event (Jan 19, 2026): The user opened the app log shows appStartTime: 2026-01-19 T13:43:39 UTC. The device seemingly pushed the pending change from the 9th again.
  • RequestId: 22795848 (Identical to the Jan 9th event).
  • Result: Success (The server processed the edit again).
  • Consequence: The row was reverted to the state based on the dataStamp from Jan 9th, overwriting 10 days of progress by other users.

The Issue: It appears the client device never received the original acknowledgement on Jan 9th, so it queued the delta. When the user opened the app on Jan 19th, it retried the sync.

Why this is a Bug: Since the RequestId matches exactly, the AppSheet server should have identified this as a duplicate transaction (Idempotency) and returned “Success” without re-executing the data change. Instead, it treated it as a new valid operation, allowing old data (stale data) to overwrite the current state of the row.

Evidence (Screenshots attached below):

  1. Audit log from Jan 19th showing current requestStartTime but old dataStamp and the reused requestId.
  2. Audit log from Jan 9th showing the original execution of requestId 22795848.

I know I have to call AppSheet Service for this but I wander whether anyone experienced a failure in de-duplication with this kind of time gap? Is there a limit to the history the server keeps for Request IDs? My plan allows for 60 days audit history but I assume that this has little to do with this problem.

Thanks for any help.

image
image1131×534 102 KB

image
image750×1250 120 KB

2 Likes
2

Legit.

Attn @Jose_Arteaga

2 Likes
3

@Steve Legit bug or legit behavior??

A uestion….In the blackbox of AppSheet, how/when are the logs written? For example, if the submission of the data on the 9th failed, would we see a log entry for it?? I would think no.

Secondly, does AppSheet have hand-shake acknowledgements or does it operate on the “send and forget” method??

I’ve never really thought too deeply about these - until now!1

1 Like
4

Thanks @Steve,

It does look like a Legit bug. We will bring it to the support team for further research.

@pbalerio, did you contact support? did they provide with a ticket ID?

2 Likes
5

Legit bug.

1 Like
6

Thanks @Jose_Arteaga and all who have answered.
Support Ticket Id# is 67097916

1 Like
7

Thank you for looking into this. However, that specific id appears to reference a bug from 2017. Could you please double-check?

1 Like
8

Yes errors and connectivity issues occur but should not go silent.

The same Request id processed with Success twice means -my hipothesis being right- that the error has not been detected by the platform/server/programmer.

1 Like
9

Hello @pbalerio,

I have been informed that this bug has escalated to the development team. I really appreciate you bringing this case to our attention!

3 Likes
10

My pleasure

3 Likes