Title: Users table only works reliably for my own row — tester rows fail to hydrate/populate consistently across app
I’m building a fairly large Glide app (“Commuter Eye”) with realtime-style operational systems including:
- Live Updates (alerts)
- Tunnel Talk (discussion threads)
- Replies
- Favorites
- Arrivals
- GPS/location logic
- Route/session state
I’ve narrowed a large number of instability issues down to what appears to be a deeper Users table / user hydration issue.
The strange part is:
MY row in the Users table works correctly and populates many computed/user-specific columns normally, while tester rows do not populate the same columns consistently (or at all).
Examples of columns that work for MY row but not reliably for testers:
- Viewing Incident ID
- Viewing Cluster Row ID
- Selected Route ID
- Nearest Stations
- User Location Coordinates
- Arrivals Web Embed URL
- Incident Count
- Favorite Routes Relation
- Draft Route/Alert state
- Push Alerts Enabled
- Editing Profile
- Various relations/lookups tied to user state
Symptoms across the app:
- Replies appear on device but not in Glide editor
- Glide editor shows replies that don’t appear on tester devices
- User profile editing inconsistently appears
- Avatars/names fail to hydrate consistently
- Arrivals previously became unstable until I removed Users dependency entirely
- Relations work for my row but not for testers
- User-specific state appears partially initialized for testers
Important observations:
- Authentication itself appears to work
- Tester rows DO exist in Users
- My row behaves normally across all systems
- Many failures disappear when operational systems stop depending on Users
- Relations and realtime-style flows become stable when I use direct row IDs/screen values instead of User Profile values
This makes me think there is some hidden issue with:
- user row hydration
- delayed user-specific initialization
- row ownership
- user-specific columns
- how Glide resolves tester sessions vs editor “Viewing As”
- or a corrupted/misaligned Users structure
Questions:
- Has anyone seen a situation where the owner/developer row hydrates correctly but tester rows do not?
- Is there a known Glide limitation with large numbers of user-specific columns?
- Could certain user-specific relations/lookups silently fail for non-owner users?
- Is there a known “best practice” for separating operational systems from Users-dependent systems in Glide?
- Has anyone successfully stabilized a large multi-user Glide app heavily using user-specific columns/relations?
I’ve attached screenshots of the Users table and several of the affected columns.
At this point I’m trying to determine whether:
- the Users architecture itself needs restructuring,
- there is a hidden configuration issue,
- or Glide’s user-specific hydration model simply becomes fragile at scale.
Any deep technical insight would be appreciated.
