Prevent event reindexing (on same HS) by only allowing a cursor to change incrementally

[ok300]

This PR brings in ok300#12 .

[SHAcollision]

Hey @ok300 , nice work!

Two concerns:

1. Backwards compatibility: I am not sure about this, but maybe the previous Homeserver cursors were previously stored in Redis as strings because of their crockford encoding (e.g., "0000000000000") ?. With the field now defined as u32 and deserialized directly from Redis, any existing cursor will fail to deserialize, causing get_from_index/validate_cursor_change to error before processing. Maybe a data migration or a custom deserializer that accepts both strings and numbers is needed to avoid runtime failures during rollout. Have you tried running this fix over an existing homeserver?

2. Cursor range maybe be too small?: The new u32 type limits cursor values to ~4.29B. If homeserver cursors can exceed this (the former 13-digit likely did), .parse::<u32>() will reject valid cursors and prevent further updates. Is the cursor on pubky-core/pubky-homeserver also u32 ? We could consider u64 (or string+numeric parsing) if we might sometimes expect larger cursors.

[ok300]

To your 1st point:

As part of the Postgres change, the HS also migrated its cursor logic such that the /events endpoint accepts both timestamp- and incremental-event-ID-based cursors, but returns the new cursor in the later, incremental ID format.

High-level view of the flow:

1. Nexus calls ?cursor={timestamp}
2. The HS recognizes the timestamp and converts it into the corresponding event ID
3. HS process the request as usual
4. HS returns the new event ID cursor
5. Nexus persists it and uses it as starting cursor in subsequent requests

In other words, when the HS version with the Postgres change went live, cursors were seamlessly migrated to the integer format. So no timestamp-based cursors remain in Nexus.

As a live example, see https://homeserver.pubky.app/events/?cursor=0032W24W13DBW&limit=10 (it returns an integer as next cursor).

Have you tried running this fix over an existing homeserver?

Yes, I ran it against the Prod HS and it works.

I also tested it against a HS with no events, where the Nexus Redis already stored its cursor as the string "0000000000000". WIth the original PR it failed, but it's fixed in the latest commit da5e471 .

It's important to note this won't work with old, pre-Postgres homeservers, as they're not using incremental event IDs.

[ok300]

To your second point:

Is the cursor on pubky-core/pubky-homeserver also u32 ?

It's i64 (link) probably due to the Postgres schema. This means the positive range is effectively u32.

If the HS gets a larger range for the event ID, we can easily adopt it.

[aintnostressin]

Have you considered migrating data in redis instead of supporting both formats ?

[aintnostressin]

Now this is going to fail each time, unless homeserver somehow returns cursor that is higher that currently stored.

Should we have a metric and get notified that syncing is stalled because of it ?

[ok300]

If the HS returns event lines, the last one will have a cursor that is higher than given cursor. For example https://homeserver.pubky.app/events/?cursor=150000&limit=1

If the given cursor doesn't exist, the HS returns no lines : https://homeserver.pubky.app/events/?cursor=250000&limit=1

this is going to fail each time, unless homeserver somehow returns cursor that is higher that currently stored

So it seems to me the condition you describe won't happen, because the HS always returns a higher cursor than the current one (arg), else returns no lines at all.

Or am I missing smth?