DRD Get Changes — Group 16, Code 147

Quick reference

Sync model

Every write to the user table (post 140, delete 143) refreshes that record’s updated_at. Deletes do not erase the row: they tombstone it (personal fields blanked, denomination + serial + deletion time kept) so a mirror that has already copied the record can learn that it is gone. Tombstones are retained for 90 days (DRD_TOMBSTONE_RETENTION), then purged.

The feed is ordered by (updated_at, den, sn) ascending and is read with a three-part cursor of the same shape. A client remembers the cursor of the last entry it received and passes it back; the server returns entries strictly after it. A cursor whose updated_at is 0 means “from the beginning” and the den/sn parts are ignored.

Sharding. The serial-number space is split into shard_count shards (1–25) by sn % shard_count. A client asks for one shard per call, so 25 shards can be pulled in parallel from 25 different RAIDAs, or a single RAIDA can be drained shard by shard. Each shard keeps its own cursor.

Modes. 0 returns live records and tombstones interleaved in feed order, 1 live records only, 2 tombstones only.

Resync. If a client presents a cursor older than the tombstone-retention window, the server may already have purged deletions that client never saw. The page is still served, but the response sets the resync_required flag; the client must discard its copy of that shard and restart from cursor 0.

Request body (60 bytes)

Response

Response payload (3 + entries)

+-------+-------+---------+---------+-----
| flags | count | entry 0 | entry 1 | ...
| 1     | 2 (BE)| var     | var     |
+-------+-------+---------+---------+-----
offset 0   1       3

Entry formats

Each entry begins with a one-byte entry_flags. Bit 0 selects the format; all other bits are reserved and zero.

Tombstone entry (entry_flags bit 0 = 1) — 14 bytes

+-------------+----+--------+------------+
| entry_flags | DN | SN     | deleted_at |
| 1 (0x01)    | 1  | 4 (BE) | 8 (BE)     |
+-------------+----+--------+------------+
offset 0        1    2        6

Live entry (entry_flags bit 0 = 0) — 1 + user record

The entry_flags byte (0x00) is followed by one user record in the standard DRD serialization, the same layout get_user (141) returns, including the trailing description field:

+-------------+----+--------+-----------+----+----+----+------------+------------+----+-------+----+------+--------+-------------+
| entry_flags | DN | SN     | inbox fee | S1 | S2 | CR | created_at | updated_at | FL | first | LL | last | DL     | description |
| 1 (0x00)    | 1  | 4 (BE) | 8 (BE)    | 1  | 1  | 1  | 8 (BE)     | 8 (BE)     | 1  | FL    | 1  | LL   | 2 (BE) | DL          |
+-------------+----+--------+-----------+----+----+----+------------+------------+----+-------+----+------+--------+-------------+
offset 0        1    2        6           14   15   16   17           25           33   34      ..   ..     ..       ..

Side effects

Although 147 is a read, it doubles as the RAIDA’s once-a-day DRD housekeeping trigger. The first call each day purges tombstones older than 90 days and runs the multi-device maintenance sweep (reaping delivered tells and pruning stale device links). These are cheap no-ops on later calls the same day and never change the page you receive.

Status codes

Common mistakes