Collisions in `updated_at` when `POST`ing `late_bytes`

[kavorite]

This report comes from @Bash-09. The offending lines are these:

masterbase/masterbase/lib.py

Lines 535 to 545 in d4cd5d3

	session_id, old_late_bytes = conn.execute(
	sa.text(
	"""SELECT session_id, late_bytes FROM demo_sessions
	WHERE steam_id = :steam_id
	AND updated_at = (
	SELECT MAX(updated_at) FROM demo_sessions WHERE steam_id = :steam_id
	);
	""",
	),
	{"steam_id": steam_id},
	).one()

Clients periodically get a 500 during header overwrites because this query returns multiple results, causing one() to throw an exception.

The easy fix is to use first() here instead of one(); still, I think it merits an investigation into why multiple entries of demo_sessions with identical updated_at fields exist. More comprehensive changes to the database schema could also make it easier to disambiguate which session the requester last interacted with.

[jayceslesar]

this is likely someone running tests against the system no? someone opening and closing sessions insanely fast?

[kavorite]

certainly not. It was just bash running a mainline build. The start and end times checked out, so I think updated_at may have been overwritten retroactively.

[kavorite]

For additional details see #87

[jayceslesar]

MegaAntiCheat/client-backend#175

[jayceslesar]

stupid race conditions

[jayceslesar]

@Bash-09 I can implement a non breaking optional param on the API side that can accept session_id as an optional param in the body of this request so that we can lazily implement that on the client backend if we think its worth it. This will allow us to explicitly update the row in the database that we need to instead of looking for what we should be updating. This is just a little scary territory because we can't control what version of the backend the clients are actually using so need to allow both and eventually deprecate and return a response that says "update your damn client" or something