tldraw/tldraw

UserDataSyncer reboot loop after database reset in dev

Open

#7 078 ouverte le 7 nov. 2025

Voir sur GitHub
 (3 commentaires) (0 réactions) (1 assigné)TypeScript (47 037 stars) (3 212 forks)batch import
good first issue

Description

Description

When developing locally with yarn dev-app, if the PostgreSQL database is reset (e.g., by removing the Docker volume), the UserDataSyncer Durable Object gets stuck in a reboot loop when users have cached browser state from before the reset.

Steps to Reproduce

  1. Start yarn dev-app and log in to the app
  2. Stop the dev server
  3. Reset the database by running: 
    cd apps/dotcom/zero-cache
yarn docker-down
docker volume rm docker_tlapp_pgdata
  4. Restart yarn dev-app
  5. Try to use the app without clearing browser storage

Expected Behavior

The app should gracefully handle the situation or provide a clear error message to the user.

Actual Behavior

The sync-worker logs show repeated errors:

[UserDataSyncer]: Error: reboot loop, waiting

The UserDataSyncer attempts to restore user state from the database but can't find the necessary history because:

  1. The browser has cached session/user IDs from before the database reset
  2. The fresh database doesn't have the historical data needed for fast reboot
  3. The syncer tries to reboot but hits the same issue repeatedly

Workaround

Clear browser storage (Application > Storage > Clear site data in Chrome DevTools) and refresh the page.

Impact

  • Affects: Local development only
  • Severity: Low (workaround is simple)
  • Frequency: Only occurs when database is reset during development

Solution

A helpful error message has been added in apps/dotcom/sync-worker/src/UserDataSyncer.ts:486-488 to guide developers to the workaround. This should help new contributors understand what's happening.

Environment

  • OS: macOS
  • Node: v22.12.0
  • Database: PostgreSQL 16.2 (Docker)

/cc @steveruizok

Guide contributeur

Stack technique
typescriptnodejspostgresqldockercloudflare
Domaine
backenddeveloper experience
Type d'issue
bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 hours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
blocked
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
clear
Prérequis
Durable Objects basicsPostgreSQL Docker setupYarn workspace understanding
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65
Direction de recherche
The issue is well documented with a clear workaround already added in apps/dotcom/sync worker/src/UserDataSyncer.ts:486-488. The remaining task may involve handling the database reset more gracefully, such as by detecting the mismatch and providing a user facing error or automatic state recovery. Investigate whether the UserDataSyncer can listen for database state changes or run a health check before attempting to restore state. Ensure that the sync worker can recover without a reboot loop.