Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RiverDB Front End - Multiple Sites - Perpetual Load data symbol #29

Open
SYRCL-Kyle opened this issue Oct 3, 2022 · 4 comments
Open
Labels
follow up Needs the submitter to follow up

Comments

@SYRCL-Kyle
Copy link

The location of Sites 70 & 71 have been fixed, thank you!

However, upon trying to pull up data for either Site 70 or 71 on the front end of RiverDB, a loading sign occurs indefinitely. Further, the URL doesn't show a specific code number for either site and so it seems like there's some issue with where it is trying to pull data from.

@SYRCL-Kyle SYRCL-Kyle changed the title RiverDB Front End - Sites 70 & 71 - cannot load data RiverDB Front End - Multiple Sites - Perpetual Load data symbol Dec 12, 2022
@SYRCL-Kyle
Copy link
Author

Sites that are showing us the loading symbol without actually loading the data/page:
3 - Below Fiddle Creek,
7 - Below Jackson Meadows Reservoir,
38 - Plavada Bridge,
39 - Lake Van Norden Bridge,
40 - Upper Castle Creek,
41 - SYR Headwaters,
44 - Kingvale,
58 - Donner WWTP,
60 - Lower Castle Creek,
70 - Deer Creek Above Nevada City,
71 - Deer Creek Below Nevada City

@thosmos
Copy link
Owner

thosmos commented Feb 5, 2023

It looks like there are two problems causing this symptom. For the newly added sites 70 & 71, the problem has been fixed.

For the other sites, it's caused by a rogue sitevisit with no date and is causing the backend query to fail. This brings up a possible bug in the data entry form which should always require a date. We also need to fix the frontend to display any query errors more prominently. But essentially, to really fix this problem we need to fix the bad data.

Here are the links to the rogue records causing the query to fail:
Site 3: https://admin.riverdb.org/sitevisit/edit/17592187192371
Site 7: https://admin.riverdb.org/sitevisit/edit/17592187179317
Site 38: https://admin.riverdb.org/sitevisit/edit/17592187208824
Site 39: https://admin.riverdb.org/sitevisit/edit/17592187208826
Site 40: https://admin.riverdb.org/sitevisit/edit/17592187208828
Site 41: https://admin.riverdb.org/sitevisit/edit/17592187208839
Site 44: https://admin.riverdb.org/sitevisit/edit/17592187208842
Site 58: https://admin.riverdb.org/sitevisit/edit/17592187209048
Site 60: https://admin.riverdb.org/sitevisit/edit/17592187209050

@thosmos
Copy link
Owner

thosmos commented Feb 5, 2023

some of these have been hidden via the publish button fix (3b6f3b9) in the data entry form, but at least one of them (site 7) had the publish button checked

@thosmos thosmos added the follow up Needs the submitter to follow up label Feb 15, 2023
@SYRCL-Kyle
Copy link
Author

Oh interesting how these rogue sitevisits without a date are causing this issue! I think your point that having the data entry form always require a date would be ideal (as I've worried about volunteers or new coordinators inadvertently losing the occasional entry in this manner).
Were/can the linked rogue sitevisits deleted such that the 'bad data' is removed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
follow up Needs the submitter to follow up
Projects
None yet
Development

No branches or pull requests

2 participants