Here's exactly what happened:

1. PR #237 added a UNIQUE INDEX to the database:

CREATE UNIQUE INDEX device_registry_user_unique

ON device_registry (tenant_id, outlet_id, logged_in_user)

1. Your production database had duplicate rows in device_registry (same captain logged in from multiple devices over time). When Railway deployed PR #237, PostgreSQL tried to create that unique index but FAILED because of those duplicates.

2. That failure broke the entire startup sequence. The migration step that warms the in-memory cache (loads all your outlet/menu/staff data into memory) never ran. Server started with empty cache.

3. Every login failed — because your email saisangeettax@gmail.com was only in the cache, not in the active memory anymore. The server only knew about the placeholder info@dinexpos.in.

4. The data itself was never deleted — it was in tenant_settings in PostgreSQL. But at some point Railway reset the PostgreSQL volume (Railway does this during certain maintenance/upgrades on free plans). That wiped tenant_settings completely.

So there were TWO problems:

PR #237 → broke login (fixed by reverting in PR #238)

Railway PostgreSQL volume reset → wiped all your outlet/menu/table/staff data

The data loss is the Railway volume reset — not our code. Our code only broke login, not the data.