So I'm trying to reject this ( www.speedrun.com/Rec_Room/run/y6pl4xjm ) run for "Suspicious video: No audio after 6:41 (video time)". But every time I hit OK after typing the reason, I get an HTTP 500 (Internal server error) error.

PS. I just noticed... speedrun.com/editrun.php?id=y6pl4xjm&action=reject editrun.php php >PHP How To Use PHP: 1. Use something else

Edit: Fix formating Edit 2: Jesus christ, you guys didn't need to make a flamewar out of this. Also rejecting the run works now.

I linked this thread in the site Discord so hopefully the admins will see it soon.

@dan9er thanks for the bug report but instead of being a smart ass about what's used for the backend of the site - take into consideration that most people who work on this site as volunteers and refactoring it into a language you'd deem as "suitable" would take a considerable amount of time.

my guess it there's a fatal happening because an object being fetched doesn't exist (the id linking to a database returns nothing) then tries to handle the object anyway, but can't as nothing is in the object.

I'll look into it at some point soon, but try not to be a jack ass in the future.

Also use this forum for issues in the future: https://www.speedrun.com/The_Site/thread/onfz6

@dan9er maybe contact @GoblinRR and ask them to delete the run or upload a video with all the sound so it gets removed from the que and also tell them it won't be verified so they won't be left wondering why there run hasn't been verified yet :) I hope this kind of helps a lil ^_^ have a good day

If the frontend is connected to an api, throw a 404 instead of a 500 (cause something is missing) if it's directly connected to the backend, then it's a programming error

I love when someone tries to tell a site developer how to develop the site.

You should read Volvagia’s post again and pay special attention to the part that mention this site is maintained by volunteers (which means that fixing every little thing can take time) as well as the part that talks about not being a smartass/jackass.

@Timmilvus so even tips aren't allowed? Dang it's going freakin downhill with mankind.

That’s not a tip, it’s useless/non-constructive feedback for something like this. This site has more pressing issues to be fixed/developed then making sure the http status codes are perfect for something like this (a 404 or a 500 is fine here and a large number of users won’t notice or care about the status cause coming back).

If you really want to get into this, a 500 is probably more correct than a 404. The user isn’t having any trouble retrieving the resource of the run in question. There’s no bad request, missing resources based on a bad URI or bad authorization, so a 4xx status code doesn’t make sense. Rather, the issue is happening because of something not linking properly in the DB and the backend is having an issue (based on Volvagia’s response/best hunch). That’s why it’s a 500 - the user didn’t do anything wrong and their query works perfectly fine, but the backend encountered any issue processing it because of the bad data. Hence, an internal sever error since the server is erroring out on a normally working piece of code. Rule of thumb is that bad requests on the user side are 4xx responses, and bad data saving/handling is a 500.

Regardless, that’s why it seemed like a smartass response, because it was irrelevant and made it seem like you were explaining to a site developer how to handle status codes (which they more than likely know).

Must be me, but I don't see anything in those posts that makes me thing they are being a jackass/smartass. Lol

If it's a 500 code that doesn't have to do with the php code itself it should be caught since it can be. Like I already said, I wasn't trying to be a smartass that's simply what you're saying I am.

The front end that you interface with is delivered by a php templating engine called twig, it is widely used. It is not connected through SRC's API, it communicates directly to the model in place that handles the respected class and serves as an interface to the MVC architecture (the twig template being the view).

The reason it's returning a 500 is because a PHP Fatal Error is occurring when trying to write back to the model. One of the linked objects does not exist any longer in the database.

Since I've joined the site there's been a few occasions of this happening where the chain of relationships aren't deleted upon a user deleting on end of the record (normally at the source).

Because it's returning a PHP Fatal Error, it's resulting in a HTTP 500 response when hit.

An example of this is when notifications were broken. Unfortunately when Pac asked me to look into it I was preoccupied with a vistor and could not look into it until a few days later. I believe Pac was also busy and could not look into it. The cron would run and try to push notifications - get to the record with the related id that didn't exist and fatal out resulting in the script from proceeding from that given process.

The issue itself with situations like these is not PHP itself but an oversight in the construct of a method, normally delete in the way that SRC is built. Somethings in the site are not built in a manner I'd normally build them, but, when you're dealing with someone else's coded which may (or may not, I've not done a git blame on it) be a few years old, you have to accept whats there and do one of two things:

• Overhaul the entire structure that's there, making sure that everything else that has a dependency doesn't fall on it's ass when you reconstruct the class

OR

• Put a bandaid on it when an error occurs and assume the rest is fine. (this is the most common approach to applications at production level - it's what say for example Twitch/Amazon, Google/YouTube, Facebook and Twitter do every single day)

The conception of PHP being a bad language is widely exaggerated - there's good practices out there for it and you're able to do some wild things with it and create some crazy applications. For scalability, yes, it's not the most convenient or friendly tool to launch enterprise tier applications, but it is used and in the modern world, used well. Some of the biggest websites in the world started on a PHP foundation until they reached such a tier that they had to focus on scalability and chose another path. (Facebook being the most notable example)

Most extensions of PHP's reputation comes from it's past where people have constructed applications with nondescript variable names, procedural methods over classes or just poorly constructed classes following no guidelines or coding standards.

I'm not saying the site's code is perfect, I'm not here to bad mouth anyone either - but at the moment with the size of the site it's maintainable. It'll need a refactor soon and depending on how much speedrunning grows we may need to look at other options. But at the moment, it does the job and to be honest has a wider reach into gathering developers than say, using Ruby on Rails (which Twitch was built on originally, now is more of an EmberJS app and also being partly reconstructed to be built on GoLang last I heard).

Please don't assume you know how the site works without access to the code.

Edited for typos. :)

@Volvagia wasn't assuming just suggesting, there's a difference that's apparently not known here but okay.

Thanks for the explanation tho.

Guys, dan9er is totally right. Let's throw the code away and rebuild the site with Weebly, like a real 10x l33t rockstar coder.

EDIT: Accidentally mixed up dan9er and Duxez. Sorry.

@Duxez I'm fully aware of the difference if you're referring to the status response codes but you're really pressing my patience.

Dang humanity going downhill right here. Everyone getting triggered over jack shit. Guess I should've expected it.

If the only way you can read what I said about status codes as if I was attacking you or something, than it's you pressing your patience.

It really isn't humanity going downhill.

They know what they're talking about, and I'd assume that if it was helpful they would appreciate it, which I'd guess it wasn't.

Don't be like 'I should've expected it' because if you don't want to seem like a jackass, and you don't think you're being one, don't say stupid stuff like that.

Since when is giving opinions and suggestions being a jackass? I'm not asking them to completely agree. I'm just saying there's no reason to act like they do. But you guys do you.

I'm just sitting here wondering why @Duxez is getting shit on and not at least OP

What I responded with is that your assumption of what the status code could mean is incorrect to the status it's used. Which I pretty much described in my explanation.

The server is trying to deliver a response but can't - it hit an unexpected output (a fatal error) and depends on the logic to proceed further.

@Komrade It's not really being shit on, more I'm losing my patience explaining that what "could" is not what is. The topic itself should be a representation of what not to do when raising a bug. :)

Further posts are warranted in this thread, but I'll lock it later as we're aware of the issue and have taken note of it.