Data Not Persisting Between Sessions — Changes Lost on Next Login

Dear Backendless Support Team,

I am experiencing a critical data persistence issue with my application and need your urgent assistance.

ISSUE

Any changes made by users during a session are lost when they log out and log back in the next day. The data reverts to the state from the previous day. If the same user logs in and out multiple times on the same day, the data remains intact. The problem occurs consistently when there is an overnight gap or any extended break between sessions.

WHAT WE HAVE VERIFIED

  • The application saves data to the Files API at auditshared/FY2026.json
  • The auditshared folder has full Read, Write, Delete, and Permission access granted to AuthenticatedUser
  • The file FY2026.json exists and shows a recent date modified timestamp
  • Database permissions for AuthenticatedUser are fully enabled for all operations
  • The session timeout is currently set to 18 days
  • Multiple logins are enabled and set to 5 simultaneous sessions

Despite all of the above being correctly configured, data changes do not survive between sessions when there is an extended gap.

REQUEST

Could you please investigate why data written to the Files API during a session is not persisting, and advise on the root cause and recommended fix?

This is affecting our entire audit team’s daily work and requires urgent attention.

Thank you.

Best regards,
Nishant Sarma

Hi @Nishant_Sarma

  1. How do you use the Files API (REST,JS-SDK, Java-SDK, etc)?
  2. are you sure your app sends requests to the Files API?
  3. how can we reproduce the problem, could you please provide with steps to reproduce (STR)
  4. do you use US or EU cluster? or perhaps you use Backendless PRO

Regards,
Vlad

Hi Vlad,

Thank you for your response. Please find answers to your questions below.

  1. HOW WE USE THE FILES API

We use the REST API directly from a single-file HTML application. Saves are made using a POST request with multipart/form-data to:
https://api.backendless.com/{APP_ID}/{API_KEY}/files/auditshared/FY2026.json?overwrite=true

The user-token is passed in the request header. Reads use a GET request to the same path with a nocache parameter.

  1. CONFIRMATION THAT THE APP SENDS REQUESTS TO THE FILES API

Yes, confirmed. The file FY2026.json is visible in the Files Browser under auditshared, and the Date Modified timestamp updates when saves occur.

  1. STEPS TO REPRODUCE

  2. Log in to the application

  3. Make any change — add a project, update a field, or add a team member

  4. Wait for the saved confirmation in the app

  5. Log out

  6. Wait several hours or until the next day

  7. Log back in

  8. The changes from Step 2 are no longer present and the data has reverted to an earlier state

Note: if the user logs out and back in on the same day, the data remains intact. The issue only occurs after an extended gap between sessions.

  1. CLUSTER

US cluster, Backendless Cloud (not PRO).

REGARDING ACCESS

As you have full access to our app on your platform, you can review everything directly in the console:

  • The application file is at: web/index.html — all the Files API logic is in the functions _doCloudSave, loadData, and _flushPendingWithBeacon
  • The data file is at: auditshared/FY2026.json
  • Session settings are under Users Management → Login → Enable Session Timeout (currently set to 18 days)

We believe the issue is related to the session token expiring mid-session when the timeout was previously set to 2 hours, causing file write requests to fail silently. We have since updated it to 18 days but would appreciate your confirmation on whether this was the cause and whether there is anything further required on the Backendless side.

Please let us know if you need anything else.

Best regards,
Nishant Sarma

thanks for the answer, let me summarize:

  1. you send a REST request to update a JSON file
  2. in the files browser you can see the file was update with latest data
  3. the you check the file in a few hours and the file is reverted to previous state (updated time and content)

is that correct?

Hi Vlad,

Points 1 and 2 are correct.

On point 3 — we have not specifically checked whether the file itself reverts in the Files Browser. What we observe is that when users log back in the next day, the application displays old data. We assumed this was because the file had reverted on the Backendless side, but it is possible the file remains correct and the issue is in how the application reads and loads it.

Best regards,
Nishant Sarma

ok, in that case I can recommend you to do additional debug your app to check this