return legacy section docs

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
 

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