Firstyear
Firstyear
Anyway, to re-summarise - we aren't against the feature, but it's just not a priority for us to implement right now.
Today no - but of these two schemes, I prefer RFC8693.
@ToxicMushroom I think this is for you
There are two separate problems here. > > Replication was broken and the replica could not sync with my primary node because there were some inconsistencies in the database. Without...
A bit rough, but this explains replication and how it works https://github.com/kanidm/kanidm/blob/master/book/src/developers/designs/replication_design_and_notes.md
> This is due to an error in refint verify incorrectly including tombstones/conflict entries. In this case, you can safely ignore this error. Actually, looks like it's not an error...
> That's easy, let's check the logs: > > ``` > 1762516107057 2025-11-07T11:48:27.057Z d56b12f0-6df0-426d-8e2b-bd2fe0c9ce28 INFO request [ 24.4µs | 100.00% ] method: GET | uri: /status | version: HTTP/1.1 >...
> > So this is telling you that there is a data issue in the incoming data. So on the source server, you need to investigate that to determine why...
This is informing you that the backup you restored from is corrupted in some manner. You may find it far easier to just setup the new server and refresh it...
I think the issue here is that we want there to be "one place where this is checked". The worst case would be that the client side rejects a password...