| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
I would have used IPv6, i.e. [::1]:5555, but our school network only has
IPv4 and it'd be easier to keep everything on the same protocol, though
this probably wouldn't matter for standard reverse proxy setups.
|
|
|
|
This is useful for testing whether connection collisions work well.
|
|
|
|
|
|
|
|
|
|
I used named returns to inspect return values (especially error values)
|
|
The entry is deleted from cancelPool if and only if cancelPool's cancel
function for the user is equal to &newCancel. This compare-and-delete
works because of locking.
|
|
Cancel occurs in async. When the cancelled function exits, it deletes
the entry in cancelPool, and could replace the new routine's cancel
function, which is of course undesirable. Therefore this commit causes
handleConn to stop deleting from cancelPool entirely.
Note that this introduces a memory leak at the size of
context.CancelFunc per user, because we are never deleting from
cancelPool.
This does not actually solve the race condition documented in
fc911928 where two new connections start sufficiently close to each
other.
|
|
When beginning to handle a WebSocket connection, we shall create a new
context, with the request context as its parent. We use the new context
for everything from now on, except for reporting error messages, which
is handled by creating a reportError function in a closure in
makeReportError and passing it along to command-handling functions.
Note that if one user attempts to rapidly launch WebSocket connections,
there might still be a race condition where the old connection hasn't
been completely established yet (i.e. an entry hasn't been added to
cancelPool) and the new connection isn't able to cancel the old
connection. I'm a bit tired to think of a solution now but it could
probably be solved by moving the cancellation registration and
cancelling sooner during the initial handshake.
Note that more parts of the event loop needs to select from ctx.Done
(from newCtx) for this to work reliably.
|
|
|
|
|
|
|
|
|
|
The new names are a bit more descriptive in what each do, and I intend
to add an "admin" template in the future.
This has no user-facing effects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously both commands used N, and deselection wasn't really
implemented on the JavaScript side. It worked and didn't throw an
exception but it's technically wrong and the user could see an empty
number field for a split second.
|
|
|
|
|
|
Currently only connects and creates a fake user
|
|
|
|
Fake authentication is useful when benchmarking the server with an
external program without going insane with the OpenID Connect forms.
|
|
|
|
|
|
Otherwise, users may get something like "TypeError: Cannot set
properties of null (setting 'checked')"
|
|
This is technically a race condition, and users with extremely slow
computers and very bad luck might get exceptions from this.
I think.
|
|
|
|
|
|
It's done in the WebSocket routines rather than in the template maker
because it's relatively easier to write the logic this way.
|
|
|
|
|
|
|
|
dogsled forbids patterns such as "_, _, _ = a, b, c" for no reason.
unparam warns about unused parameters even when I'm assigning them to _
to indicate that it's fine for them to be unused.
|
|
|
|
|
|
|
|
When a user has already chosen a course choice but sends a message to
choose it again, a database error occurs as the uniqueness constraint is
violated. In this case, we "reaffirm" the user's course choice, to
hopefully get their client's state back in sync.
However, we previously forgot to return back to the event loop after
this reaffirmation, causing the control flow to fall into the
course-increment and transaction-commit stage. The error is discovered
at tx.Commit, where pgx raises a ErrTxCommitRollback, because in that
case we're trying to commit a transaction that has already encountered
an error.
|
|
I don't think password authentication is really useful, since
Microsoft Entra ID is the "proper" way of doing authentication in our
school system and there's just little reason to have a password login.
I previously wanted to use password authentication for stress testing,
but stress testing really could just use completely fake authentication
and there's no need for any password whatsoever.
|
|
When an unknown database error is encoutered, the connection should be
considered broken and the error should be reported as a fatal error to
the end user. Rejecting the course choice unsets the checkbox and lets
the page to be continued to be used, which is not intended.
|
|
handleIndex and handleConn used to access the courses map without
RLock'ing coursesLock, which may cause issues if courses is being
written to, by a function such as setupCourses.
|
|
|
|
|
