Unable to purge data after partial race start and stop

[brownnrl]

Ran into an issue tonight, where I was just trying to test everything together.

Had a big roster of 155 scouts, and started a race with 24 scouts in a Lion den.

Bulk check in Lion, over to race dashboard, schedule+race Lion, run 4 heats (getting replay camera and kiosk working), everything working, press stop racing.

Back to setup, purge data race results. No good. Purge data schedules. Nothing. Repeat tries, nothing.

Eventually because just testing everything out ended up re-initializing database and re-importing from a file.

I can see after tomorrow if I can re-create. Any logs somewhere I can post? This might also just be not the recommended way of doing things which I totally get.

Thanks for awesome software! Versions I can think of to post below!

apt list -a derbynet-server
Listing... Done
derbynet-server/stable,now 9.0-1718 all [installed]

apt list -a derbynet-extras
Listing... Done
derbynet-extras/stable,now 9.0-1718 all [installed]

Linux labbox 6.5.0-25-generic #25~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

[jeffpiazza]

/var/log/nginx/access.log and (maybe especially) /var/log/nginx/error.log.

Were there error messages or similar when the purge operations were unsuccessful?

[brownnrl]

Access logs uploaded. I don't see any errors related to the database purge.

I actually can't recall if I got any particular errors after the confirmation to purge. The data was just still there after multiple attempts. I don't see anything in the error logs. I'm going to take the timer home today after the race and see if I can't replicate in a new database file.

derby_logs.tar.gz

[jeffpiazza]

Thanks for these!

I don't see an entry for a purge action (action=database.purge), although I do see one for re-initializing the database (action=database.execute&script=schema) at 21:18:26.

The logs also show the setup.php page (from which a purge action would originate) being loaded at 20:04:12, and then at 21:18:05 (a few seconds before the re-initialize action).

The setup page doesn't get refreshed as the database changes. I'm wondering if you tried doing a purge from setup tab that was still open from the start of your experiments, and that tab had stale data indicating there was nothing to purge. This isn't a terribly strong theory, though: the various purge buttons should have been dimmed to reflect the belief there was nothing to purge, and you likely would have noticed that.

[brownnrl]

First off, scout is courteous, your software is awesome. Ran 88 scouts through a district derby, had a check in station with an ipad, ran the server with a single wifi with no internet, had a replay kiosk with remote camera where we did the now-racing and awards presentations, I had my tablet for running while stacking the the cars onto the lanes, and we had a racers on deck view! The only complaint I got was that we were too quick and efficient! So THANK YOU so much for this software it was awesome. I'm trying to get everyone into it that runs these.

As far as this bug, I am able to reproduce. There is some earlier items from the computer with me downloading the standings, but starting with the creation of a fresh database. Did this though maybe not exactly in this order (have to go through access log for exact order), but really close to this order that I'm confident the issue would repeat.

1. Went to new race check in, created two dens Den1 and Den2 with 8 racers with first names A-H and last name "Den1" in Den1 and added four racers with A-D and last name "Den2" in Den2.
2. Bulk check in Den1 from the race check in.
3. Go to Setup -> Settings -> set lanes to four lanes.
4. Go to race dashboard (I think I may have done one test of the timer).
5. Schedule + Race Den1.
6. Run 4 of the 8 heats.
7. Go back to Setup
8. Go to Purge Data => Purge Schedule => Get Confirmation => Select OK.
9. Got to Purge Data => Purge Results => Get Confirmation => Select OK.

Race is still schedule and ongoing. Select "Not racing", repeat 8+9, no change. There is no option to unschedule.

Use case was just integration testing with all kiosks and stations night before. I would have just re-initialized the database at that point, but I didn't have the full roster (uploaded accessing from another computer with bigger screen so it was easier to organize information). I'll know better for next time and have a CSV with roster on the machine, but had to drag it back home again just to make sure it was good for the next morning.

This is probably a low-priority back burner thing. I'm not super familiar with PHP, but if it stays on the back burner long enough I can take a stab at a PR later (but can't promise anything).

Attached is the logs and new database file from the above procedure. Thank you again!

[brownnrl]

Won't take the attachments for some reason even with the .tgz extension. Uploaded to Google Drive instead

Here is the database (tar gzip'd): https://drive.google.com/file/d/1-ByaTvnTzxct8FSwlWHoYK8SsAnWqzae/view?usp=sharing

Here is the logs (tar gzip'd): https://drive.google.com/file/d/1xt38IIgfGL1sKkDy5-DKWsWIwCJKgcCc/view?usp=sharing

[brownnrl]

It might be a Firefox thing! I tried purging the data on Chrome on a different computer and purging schedules worked. Firefox 123.0.1 64-bit gave the following errors in the developer console:

Object { type: "ajaxError", timeStamp: 1710768865551, jQuery191020731772049999353: true, isTrigger: true, namespace: "", namespace_re: null, result: undefined, target: HTMLDocument http://localhost/derbynet/setup.php?, delegateTarget: HTMLDocument http://localhost/derbynet/setup.php?, currentTarget: HTMLDocument http://localhost/derbynet/setup.php?, … }
setup.php:175:11

Object { readyState: 0, getResponseHeader: getResponseHeader(e), getAllResponseHeaders: getAllResponseHeaders(), setRequestHeader: setRequestHeader(e, t), overrideMimeType: overrideMimeType(e), statusCode: statusCode(e), abort: abort(e), state: state(), always: always(), then: then(), … }
setup.php:176:11

[subpop]

I've just been testing a DerbyNet installation for my upcoming Derby, and ran into this same issue. I was able to purge the results using Chrome, but not with Firefox or Safari.

[nauticus25]

I also ran into this issue. Purging worked on the RPi which was running DerbyNet, but not on my laptop. I thought it was a local/remote thing, but the RPi was running the Chromium browser and the laptop was running Firefox. I did not have time to troubleshoot further, so I didn't try other browsers on the laptop.

[brownnrl]

Including an event.preventDefault() seems to correct the issue, though I havent' tested it extensively. Added it to one spot, and test purging on Firefox and it worked. I believe firefox is doing a form submission to setup.php and maybe the ajax call doesn't get a chance to finish? Not sure. This would probably indicate similar action would have to be taken on any ajax call (if this is the right fix).

So in my local version setup.js in the function confirm_purge.

function confirm_purge(purge) {
  var text = "some data";
  if (purge == 'results') {
    text = $("#purge_results_para").text();
  } else if (purge == 'schedules') {
    text = $("#purge_schedules_para").text();
  } else if (purge == 'racers') {
    text = $("#purge_racers_para").text();
  } else if (purge == 'awards') {
    text = $("#purge_awards_para").text();
  }

  $("#purge_operation").text(text);

  show_secondary_modal("#purge_confirmation_modal", function(event) {
    close_secondary_modal("#purge_confirmation_modal");
    $.ajax('action.php',
           {type: 'POST',
            data: {action: 'database.purge',
                   purge: purge},
            success: function(data) {
              report_success_json(data);
            },
            error: function(event, jqXHR, ajaxSettings, thrownError) {
              report_failure(thrownError);
            }
           });
    event.preventDefault(); // added preventDefault call
  });
}

[brownnrl]

This may be relevant: "I recall that Firefox defaults a to a submit button."

https://stackoverflow.com/questions/2480859/form-submits-in-firefox-when-any-button-on-page-is-clicked

And from MDN:

button (its default type is "submit")

https://developer.mozilla.org/en-US/docs/Glossary/Submit_button

[jeffpiazza]

Thank you for the detailed investigation!

The default action for a submit button is (naturally) to submit the enclosing form. For most of the modal dialogs, the <form> element doesn't specify an action or method, so, by default, the form triggers a GET to the original page, effectively reloading the page. This can cause any pending AJAX queries to be canceled.

I'm adding a preventDefault call in the submit handler registered in show_modal, which will make it apply across the board.