| Commit message (Collapse) | Author | Age | |
|---|---|---|---|
| * | Clean up use of bare tuple as a vector element for ResumePoint. | Owen Jacobson | 2024-09-28 |
| | | |||
| * | Expire channels, too. | Owen Jacobson | 2024-09-28 |
| | | |||
| * | Delete expired messages out of band. | Owen Jacobson | 2024-09-28 |
| | | | | | | | | | Trying to reliably do expiry mid-request was causing some anomalies: * Creating a channel with a dup name would fail, then succeed after listing channels. It was very hard to reason about which operations needed to trigger expiry, to fix this "correctly," so now expiry runs on every request. | ||
| * | Assign sequence numbers from a counter, not by scanning messages | Owen Jacobson | 2024-09-28 |
| | | |||
| * | Push message body into its own object in events | Owen Jacobson | 2024-09-28 |
| | | |||
| * | Send created events when channels are added. | Owen Jacobson | 2024-09-28 |
| | | |||
| * | Make `/api/events` a firehose endpoint. | Owen Jacobson | 2024-09-27 |
| | | | | | | | | | It now includes events for all channels. Clients are responsible for filtering. The schema for channel events has changed; it now includes a channel name and ID, in the same format as the sender's name and ID. They also now include a `"type"` field, whose only valid value (as of this writing) is `"message"`. This is groundwork for delivering message deletion (expiry) events to clients, and notifying clients of channel lifecycle events. | ||
| * | Fix test missed in cce1ab45db0de5e912fa7eec8d8a2cfe9a314078 | Owen Jacobson | 2024-09-27 |
| | | |||
| * | Stream over results while OK, using less code. | Owen Jacobson | 2024-09-25 |
| | | | | | This also has the happy effect of removing an unwrap. This feels like a more coherent way of achieving the same result. | ||
| * | Missed one when drafting the tests. | Owen Jacobson | 2024-09-25 |
| | | |||
| * | Remove some extraneous turbofish operators. | Owen Jacobson | 2024-09-25 |
| | | |||
| * | `sequence` was not intended to appear in messages. | Owen Jacobson | 2024-09-25 |
| | | |||
| * | More reorganizing. | Owen Jacobson | 2024-09-25 |
| | | |||
| * | Typo in test name | Owen Jacobson | 2024-09-25 |
| | | |||
| * | Crank up the Clippy warnings. | Owen Jacobson | 2024-09-25 |
| | | | | | This'll catch style issues, mostly. | ||
| * | rustdoc comment for the (very limited) public API of the crate. | Owen Jacobson | 2024-09-25 |
| | | | | | | | | | This silences some `-Wclippy::pedantic` warning, and it's just a good thing to do. I've made the choice to have the docs comment face programmers, and to provide `hi --help` and `hi -h` content via Clap attributes instead of inferring it from the docs comment. Internal (private) "rustdoc" comments have been converted to regular comments until I learn how to write better rustdoc. | ||
| * | Code organization changes considered during implementation of ↵ | Owen Jacobson | 2024-09-25 |
| | | | | | vector-of-sequence-numbers stream resume. | ||
| * | Use a vector of sequence numbers, not timestamps, to restart /api/events ↵ | Owen Jacobson | 2024-09-25 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | streams. The timestamp-based approach had some formal problems. In particular, it assumed that time always went forwards, which isn't necessarily the case: * Alice calls `/api/channels/Cfoo` to send a message. * The server assigns time T to the request. * The server stalls somewhere in send() for a while, before storing and broadcasting the message. If it helps, imagine blocking on `tx.begin().await?` for a while. * In this interval, Bob calls `/api/events?channel=Cfoo`, receives historical messages up to time U (after T), and disconnects. * The server resumes Alice's request and finishes it. * Bob reconnects, setting his Last-Event-Id header to timestamp U. In this scenario, Bob never sees Alice's message unless he starts over. It wasn't in the original stream, since it wasn't broadcast while Bob was subscribed, and it's not in the new stream, since Bob's resume point is after the timestamp on Alice's message. The new approach avoids this. Each message is assigned a _sequence number_ when it's stored. Bob can be sure that his stream included every event, since the resume point is identified by sequence number even if the server processes them out of chronological order: * Alice calls `/api/channels/Cfoo` to send a message. * The server assigns time T to the request. * The server stalls somewhere in send() for a while, before storing and broadcasting. * In this interval, Bob calls `/api/events?channel=Cfoo`, receives historical messages up to sequence Cfoo=N, and disconnects. * The server resumes Alice's request, assigns her message sequence M (after N), and finishes it. * Bob resumes his subscription at Cfoo=N. * Bob receives Alice's message at Cfoo=M. There's a natural mutual exclusion on sequence numbers, enforced by sqlite, which ensures that no two messages have the same sequence number. Since sqlite promises that transactions are serializable by default (and enforces this with a whole-DB write lock), we can be confident that sequence numbers are monotonic, as well. This scenario is, to put it mildly, contrived and unlikely - which is what motivated me to fix it. These kinds of bugs are fiendishly hard to identify, let alone reproduce or understand. I wonder how costly cloning a map is going to turn out to be… A note on database migrations: sqlite3 really, truly has no `alter table … alter column` statement. The only way to modify an existing column is to add the column to a new table. If `alter column` existed, I would create the new `sequence` column in `message` in a much less roundabout way. Fortunately, these migrations assume that they are being run _offline_, so operations like "replace the whole table" are reasonable. | ||
| * | Write tests. | Owen Jacobson | 2024-09-20 |
| | | |||
| * | Push the handling of the `Last-Event-Id` _format_ inside of `channels::app`. | Owen Jacobson | 2024-09-20 |
| | | | | | This is intended to make it a bit more opaque to callers, and to free me up to experiment with the event ID format. It also makes event IDs tractable for testing. | ||
| * | Push events into a module structure consistent with the rest of the project. | Owen Jacobson | 2024-09-20 |
 |
index : pilcrow | |
| Run-It-Yourself web chat, maybe |
| summaryrefslogtreecommitdiff |