-
-
Notifications
You must be signed in to change notification settings - Fork 871
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
Draw generator fails when no metrics are provided #1108
Comments
That is not really enough information to determine what is the problem. However, your site did send an error report, so I'll be examining through that (BACKEND-1QA). Do you have team metrics set? Go to https://v-potiguar.herokuapp.com/vpotiguar2019/admin/options/standings/ and put "Wins" under "Team standings precedence". Or was it already set? |
Try going to the Heroku dashboard ( https://dashboard.heroku.com/apps/sucdi-tabs?web-console=v-potiguar ) and create a new user. Click on the "More" dropdown (top-right) and select "Run Console". From there, type |
I created the SU as you said and then reached to standins and put 'Wins'. It wasn't set. What should I do now? Because I still can't create the draw for Round 4, as I said before. |
GOOD NEWS! It has returned to work! So much thanks for the helping! |
Did you save the preferences? You should be able to create the draw for round 4 now... Oh great! |
Thanks for the report @ArthurPaiva, and thanks for diagnosing it @tienne-B! Would I be understanding it right if I said that the issue seems to be that the system crashes when the team standings metrics are blank? If so, we should probably do something more graceful than throw a 500 in this circumstance, right? |
Yeah, exactly, @czlee. And for what's worth, I agree with you. xD |
A warning could be placed on the availabilities page if power-pairing without metrics, or use |
Hmm, the preference form shouldn't even be permitting it to save at all if the metrics are blank… |
Oh damn okay, so I had to make This means there are two distinct issues:
|
Related: #749 Apparently I once put in a fix to protect against a similar situation… when there's only one metric in the precedence. |
Actually, having thought about it more, there's no intrinsic reason Tabbycat should just refuse to run if the tab director didn't specify any team metrics. Everything in principle can still run, it'll just be very boring: everyone will trivially have exactly the rank. Or should we just enforce it to make our lives simpler? Thoughts, @tienne-B @philipbelesky? |
Um I think that it’s probably best to try and enforce it within the form as that is probably the best time for a user to understand the behaviour. Ideally it should also run if that behaviour is somehow set, but maybe display a warning highlighting why the rankings will look wrong. |
Oh, sorry, my phrasing was poor. Obviously we should do something on the form. What I mean is: Enforce, or warn only? To elaborate: "Enforce" means refuse to save preferences with a blank standings precedence, and raise a I think we should be consistent between the preferences form and the draw/standings pages, i.e. either preference validation is enforced and it raises a (graceful) error if bad, or warnings appear in both places. Basically the question whether we feel strongly enough about this to cut the option off from users entirely (given that our general default is to let users shoot themselves in the foot if they have good reason for doing so, but warn them about what they're doing). |
Hmm, I would lean on the side of enforce in the absence of a valid use case. We have a similar safeguard in place for the |
Potential use cases:
Whether these are "valid" is… well, open to argument, I guess. (The |
This rewrites metricgetter() to avoid using Python's itemgetter(), so that the function it returns will always return a tuple. This simplifies a lot of handling, because it avoids the special case where itemgetter(item) called with one argument returns a single item rather than a tuple of length 1. As a consequence, the case where no metrics are specified now shouldn't crash. Also added standings test for this case.
Okay, with 6f3e8dc I've pretty much just made it so it works fine with no metrics, I guess (while simplifying some related code). I think this means I'd now lean towards warning only. |
This rewrites metricgetter() to avoid using Python's itemgetter(), so that the function it returns will always return a tuple. This simplifies a lot of handling, because it avoids the special case where itemgetter(item) called with one argument returns a single item rather than a tuple of length 1. As a consequence, the case where no metrics are specified now shouldn't crash. Also added standings test for this case.
This rewrites metricgetter() to avoid using Python's itemgetter(), so that the function it returns will always return a tuple. This simplifies a lot of handling, because it avoids the special case where itemgetter(item) called with one argument returns a single item rather than a tuple of length 1. As a consequence, the case where no metrics are specified now shouldn't crash. Also added standings test for this case.
This rewrites metricgetter() to avoid using Python's itemgetter(), so that the function it returns will always return a tuple. This simplifies a lot of handling, because it avoids the special case where itemgetter(item) called with one argument returns a single item rather than a tuple of length 1. As a consequence, the case where no metrics are specified now shouldn't crash. Also added standings test for this case.
This rewrites metricgetter() to avoid using Python's itemgetter(), so that the function it returns will always return a tuple. This simplifies a lot of handling, because it avoids the special case where itemgetter(item) called with one argument returns a single item rather than a tuple of length 1. As a consequence, the case where no metrics are specified now shouldn't crash. Also added standings test for this case.
* Make standings generation more robust #1108 This rewrites metricgetter() to avoid using Python's itemgetter(), so that the function it returns will always return a tuple. This simplifies a lot of handling, because it avoids the special case where itemgetter(item) called with one argument returns a single item rather than a tuple of length 1. As a consequence, the case where no metrics are specified now shouldn't crash. Also added standings test for this case. * Fix bug where extra metrics cause standings to crash Also added a unit test for this scenario * Add user alerts for blank standings precedence #1108
I hit an internal server error while trying to load this URL:
https://v-potiguar.herokuapp.com/vpotiguar2019/admin/draw/round/4/create/
Please describe what you were doing when the error happened, along with any other useful information:
Whenever try to generate a draw to round 4 on my tournment, this error displays:
The text was updated successfully, but these errors were encountered: