refactor(federation): store verified epoch as peer baseline; drop redundant assertion
This commit is contained in:
@@ -271,7 +271,6 @@ describe('POST /api/federation/peer/initiate — 202 token capture & 200 clear',
|
||||
.where(eq(schema.federationPeers.origin, 'https://remote.example')).get();
|
||||
expect(peer?.status).toBe('needs_attention');
|
||||
expect(peer?.needsAttentionReason).toBe('repeer_incomplete');
|
||||
expect(peer?.status).not.toBe('active');
|
||||
});
|
||||
|
||||
it('(c) on 200 with a valid signed epoch, activates (verified:true) and clears needsAttentionReason', async () => {
|
||||
|
||||
@@ -1001,7 +1001,11 @@ export async function federationRoutes(app: FastifyInstance): Promise<void> {
|
||||
}
|
||||
|
||||
db.update(schema.federationPeers)
|
||||
.set({ status: 'active', lastSeenAt: Date.now(), instanceName: remoteInstanceName, peerInstanceId: remoteInstanceId, needsAttentionReason: null, approvalToken: null })
|
||||
// The baseline is trust-consequential (design §9 — a poisoned baseline can drive
|
||||
// a spurious heal), so store the epoch we cryptographically verified via the signed
|
||||
// /epoch round-trip, not the unverified handshake-response body. They are normally
|
||||
// identical; the verified one is authoritative if they ever differ.
|
||||
.set({ status: 'active', lastSeenAt: Date.now(), instanceName: remoteInstanceName, peerInstanceId: verifiedEpoch, needsAttentionReason: null, approvalToken: null })
|
||||
.where(eq(schema.federationPeers.id, peerId))
|
||||
.run();
|
||||
connectionManager.sendToAdmins({ type: 'federation_peers_changed' as const });
|
||||
|
||||
Reference in New Issue
Block a user