From 5f4a99c0da4a9a96bfd5939a5a9bc999f1ac4f9f Mon Sep 17 00:00:00 2001 From: Taddes Date: Fri, 7 Jun 2024 14:53:58 -0400 Subject: [PATCH] return legacy section docs --- docs/src/architecture.md | 6 ++++++ docs/src/table_rotation.md | 12 +++++++----- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/docs/src/architecture.md b/docs/src/architecture.md index 8e27d4d0c..0430cb96d 100644 --- a/docs/src/architecture.md +++ b/docs/src/architecture.md @@ -128,6 +128,7 @@ router record for a `UAID`. | router_type | Router Type (See [`autoendpoint::extractors::routers::RouterType`]) | | node_id | Hostname of the connection node the client is connected to. | | connected_at | Precise time (in milliseconds) the client connected to the node. | +| last_connect | **global secondary index** - year-month-hour that the client has last connected. | | curmonth | Message table name to use for storing `WebPush` messages. | Autopush DynamoDB used an optimistic deletion policy for `node_id` to avoid @@ -140,6 +141,10 @@ If an endpoint node discovered during a delivery attempt that the `node_id` on record did not have the client connected, it would clear the `node_id` record for that `UAID` in the router table. +The `last_connect` was a secondary global index to allow for +maintenance scripts to locate and purge stale client records and +messages. + Clients with a `router_type` of `webpush` drain stored messages from the message table named `curmonth` after completing their initial handshake. If the `curmonth` entry was not the current month then it updated it to @@ -157,6 +162,7 @@ that are of the `router` family. These values are similar to the ones listed abo | router_type | Router Type (See [`autoendpoint::extractors::routers::RouterType`]) | | node_id | Hostname of the connection node the client is connected to. | | connected_at | Precise time (in milliseconds) the client connected to the node. | +| last_connect | year-month-hour that the client has last connected. | ### Message Table Schema diff --git a/docs/src/table_rotation.md b/docs/src/table_rotation.md index 21d93c677..403057582 100644 --- a/docs/src/table_rotation.md +++ b/docs/src/table_rotation.md @@ -36,18 +36,20 @@ on the prior month may then be lowered. ## DynamoDB Rotating Message Table Interaction Rules (legacy) Due to the complexity of having notifications spread across two tables, -several rules are used to avoid losing messages during the month +several rules were used to avoid losing messages during the month transition. The logic for connection nodes is more complex, since only the connection node knows when the client connects, and how many messages it has read through. -When table rotation is allowed, the router table uses the `curmonth` -field to indicate the last month the client has read notifications -through. This field is updated for a new month when the client connects **after** -it has ack'd all the notifications out of the last month, since it is possible +When table rotation was allowed, the router table used the `curmonth` +field to indicate the last month the client had read notifications +through. This was independent of the last_connect since it was possible for a client to connect, fail to read its notifications, then reconnect. +This field was updated for a new month when the client connected **after** +it had ack'd all the notifications out of the last month. + To avoid issues with time synchronization, the node the client is connected to acts as the source of truth for when the month has flipped