From c4c9ddfe242d4d9f9665fa64e2f915f5f3a9d2a2 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Tue, 24 Feb 2026 23:11:30 -0500 Subject: [PATCH] test: restore MaxAgeMs values in cluster tests after timestamp fix Now that MemStore uses Unix epoch timestamps (13a3f81), restore the original Go MaxAge values that were previously omitted as workarounds: - JsCluster2: MaxAgeMs=500 (Go: 500ms) - JsCluster34: MaxAgeMs=5000 (Go: 5s) --- .../Cluster/JsCluster2GoParityTests.cs | 19 ++++++++++--------- .../Cluster/JsCluster34GoParityTests.cs | 13 ++++++++----- 2 files changed, 18 insertions(+), 14 deletions(-) diff --git a/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster2GoParityTests.cs b/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster2GoParityTests.cs index 188e600..2c18238 100644 --- a/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster2GoParityTests.cs +++ b/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster2GoParityTests.cs @@ -119,16 +119,14 @@ public class JsCluster2GoParityTests { await using var cluster = await JetStreamClusterFixture.StartAsync(3); - // Note: MaxAgeMs omitted — the .NET MemStore stores timestamps as Ticks*100 (nanoseconds - // since year 0001) which overflows long, yielding a timestamp in year ~272 AD. Any - // MaxAgeMs value would immediately prune all messages. The core behavior under test is - // that consumer ack-pending tracking works correctly with freshly published messages. // Go ref: server/jetstream_cluster_2_test.go:309 (TestJetStreamClusterAckPendingWithExpired) + // Go: MaxAge = 500ms var resp = cluster.CreateStreamDirect(new StreamConfig { Name = "ACKPENDING", Subjects = ["ackpend.>"], Replicas = 3, + MaxAgeMs = 500, }); resp.Error.ShouldBeNull(); @@ -147,12 +145,15 @@ public class JsCluster2GoParityTests { await using var cluster = await JetStreamClusterFixture.StartAsync(3); - // Note: MaxAgeMs omitted — the .NET MemStore uses Ticks*100 nanosecond timestamps that - // overflow long, causing the stored timestamp to resolve to year ~272 AD. With any - // MaxAgeMs set, all messages are immediately pruned. The core behavior under test - // is that stream state correctly tracks published message count. // Go ref: server/jetstream_cluster_2_test.go:309 (TestJetStreamClusterAckPendingWithExpired) - var resp = await cluster.CreateStreamAsync("EXPIRING", ["expire.>"], replicas: 3); + // Go: MaxAge = 500ms + var resp = cluster.CreateStreamDirect(new StreamConfig + { + Name = "EXPIRING", + Subjects = ["expire.>"], + Replicas = 3, + MaxAgeMs = 500, + }); resp.Error.ShouldBeNull(); const int toSend = 100; diff --git a/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster34GoParityTests.cs b/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster34GoParityTests.cs index f30f412..699c35a 100644 --- a/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster34GoParityTests.cs +++ b/tests/NATS.Server.Tests/JetStream/Cluster/JsCluster34GoParityTests.cs @@ -28,13 +28,16 @@ public class JsCluster34GoParityTests // Go: TestJetStreamClusterStreamMaxAgeScaleUp — jetstream_cluster_3_test.go:3001 // After scale-up the replica group is re-created with the new replica count. // Messages published before scale-up must still be present. - // Note: MaxAgeMs is omitted because the .NET MemStore uses Ticks*100 nanosecond - // timestamps that overflow long, causing immediate message expiration in tests. - // The core behavior under test is that messages survive scale-up. + // Go: MaxAge = 5s await using var cluster = await JetStreamClusterFixture.StartAsync(3); - // Use CreateStreamAsync (MaxAgeMs=0, no pruning) to test scale-up message preservation. - var createResp = await cluster.CreateStreamAsync("SCALEAGE", ["sa.>"], replicas: 1); + var createResp = cluster.CreateStreamDirect(new StreamConfig + { + Name = "SCALEAGE", + Subjects = ["sa.>"], + Replicas = 1, + MaxAgeMs = 5_000, + }); createResp.Error.ShouldBeNull(); for (var i = 0; i < 10; i++)