Travel Mapping
User Discussions => Welcome & Notices => Topic started by: Markkos1992 on November 15, 2022, 06:31:19 am
-
Looks like last night's update failed. It seems to still be going.
-
I synced my branch up with the master this morning and ran datacheck.sh on it to see if I could find the error. It worked successfully with no errors found.
I don't know what the problem is then.
-
Site looks good now.
-
https://github.com/TravelMapping/HighwayData/commit/898679bf4fd52a3471882114d14200d278fcb6a3
-
Bottom line: I wasn't careful bringing in an email update and didn't notice the extraneous changes to one csv file, then went to bed after starting the site update instead of verifying its completion. Should be all good now!
-
I synced my branch up with the master this morning and ran datacheck.sh on it to see if I could find the error. It worked successfully with no errors found.
I don't know what the problem is then.
Weird. The fix (https://github.com/TravelMapping/HighwayData/commit/573e14e6bdd4ffd8df94713d00cd432dca233e70) wasn't committed until after this post.
Looks like last night's update failed. It seems to still be going.
I assume you saw the red "update in progress" banner atop one of the pages.
This is triggered by the presence of the dbupdating file created during the site update process (https://github.com/TravelMapping/DataProcessing/blob/b570b6a/siteupdate/python-teresco/localupdate.sh#L50). If siteupdate.py fails, localupdate.sh exits (https://github.com/TravelMapping/DataProcessing/blob/b570b6a/siteupdate/python-teresco/localupdate.sh#L76) without deleting the file (https://github.com/TravelMapping/DataProcessing/blob/b570b6a/siteupdate/python-teresco/localupdate.sh#L109).
I see few different ways to deal with this:
1. No-build.
2. Create a different file upon failure, which the web pages can detect and produce a new banner, "most recent site update failed" or somesuch.
3. Just quietly delete the dbupdating file upon failure.
4. Remove the dbupdating / banner functionality altogether. Without looking into it, I assume this predates the switch to the two-database (TravelMapping, TravelMappingCopy) model, and isn't really necessary anymore as when an update completes we switch seamlessly from the old to new DB and life goes on for site users.
The downside to #3-4 is it's a more transparent failure mode. Maybe an email notification (https://github.com/TravelMapping/DataProcessing/blob/b570b6a/siteupdate/python-teresco/localupdate.sh#L137-L142) for failed updates would be a good idea.
-
I think an email notification of a failed update would be most helpful. I would probably have seen an email notification on some device after launching the update but I didn't look back at the terminal where I launched the update or at TM itself until this morning.
In this particular case, I should have caught the mistake. I normally do a git diff before the commit and push of HighwayData updates I get by email. I would have seen unexpected changes in usawi.csv and fixed them. I should probably also just go ahead and run datacheck at least on my Mac before I commit and push such emailed updates.
-
Bottom line: I wasn't careful bringing in an email update and didn't notice the extraneous changes to one csv file, then went to bed after starting the site update instead of verifying its completion. Should be all good now!
So, my fault again?
-
Both of us, really. The usawi.csv you sent had two errors in addition to the correct addition of WI 311. A malformed entry for WI36BusBur and an entry that shouldn't have been there at all anymore for WI42BusMan. Then I should have done my usual check with a git diff any time I get an email update of a .csv file, which would have quickly brought my attention to these two errors. Looking back, those changes were previously made to the production version in GitHub when I asked Marrkos1992 to get a large update from you in September into GitHub, and the .csv changes were not communicated back to you.