| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Laggy clients, extremely fast clicks, or other conditions could cause
duplicate course choices to be sent, which would violate the uniqueness
constraint. In this case the fact that the user has already chosen the
course should be reaffirmed, rather than making it look like their
choice was rejected.
|
|
|
|
|
|
| |
I think the new name better reflects the fact that it just ignores
failures when propagating to each channel. The old name sounds like
"this function itself could fail".
|
|
|
|
| |
References: https://todo.sr.ht/~runxiyu/cca/1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this naive implementation currently allows users to submit
multiple requests for the same course. See the TODO comment below:
/*
* TODO: Ensure that the user is not already enrolled in this course
* and pay attention to relevant race conditions. It might be useful
* to restructure this part, to begin a transaction that adds the user
* to the database (and check the (currently not existing) uniqueness)
* constraint at that exact moment, and abort the transaction if the
* course limit is exceeded.
* Or perhaps choices should be also stored in an internal data
* structure, though that requires extra attention on consistency
* issues between the internal data structure and the database.
* (Sometime I should really go fix the LMDB bindings...)
*/
References: https://todo.sr.ht/~runxiyu/cca/1
|
|
|
|
|
| |
This allows SQL statements to be logged which makes debugging much
easier. Also "$@" is added so any extra arguments may be passed.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Cgit was kinda broken in serving HTML, it was a caching issue
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also use TryLock in setupChanPool, and fail when not successful.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
One user shall only have one session at a time. This reduces the
possibility of strange race conditions and simplifies the code a lot.
References: https://todo.sr.ht/~runxiyu/cca/4
|
| |
|
| |
|
|
|
|
|
| |
Previously, if it receives a message like "a b :c", it returns "["a",
"b", "c "]" which is erroneous.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
When propagate tries to propagate a message to a connection that
actually called propagate, it deadlocks because the it tries to send to
that connection's send channel in the same goroutine. This is an attempt
at a fix.
|