nats.zig/tests/subscription.zig

180 lines
5.4 KiB
Zig
Raw Normal View History

// This file is licensed under the CC0 1.0 license.
// See: https://creativecommons.org/publicdomain/zero/1.0/legalcode
const std = @import("std");
const nats = @import("nats");
const util = @import("./util.zig");
test "nats.Subscription" {
var server = try util.TestServer.launch(.{});
defer server.stop();
try nats.init(nats.default_spin_count);
defer nats.deinit();
const connection = try nats.Connection.connectTo(server.url);
defer connection.destroy();
const message_subject: [:0]const u8 = "hello";
const message_reply: [:0]const u8 = "reply";
const message_data: [:0]const u8 = "world";
const message = try nats.Message.create(message_subject, message_reply, message_data);
defer message.destroy();
{
const subscription = try connection.subscribeSync(message_subject);
defer subscription.destroy();
try subscription.autoUnsubscribe(1);
try subscription.setPendingLimits(.{ .messages = 10, .bytes = 1000 });
_ = try subscription.getPendingLimits();
_ = try subscription.getPending();
_ = try subscription.getMaxPending();
try subscription.clearMaxPending();
_ = try subscription.getDelivered();
_ = try subscription.getDropped();
_ = try subscription.getStats();
_ = try subscription.queuedMessageCount();
_ = subscription.getId();
const subj = subscription.getSubject() orelse return error.TestUnexpectedResult;
try std.testing.expectEqualStrings(message_subject, subj);
try connection.publishMessage(message);
const roundtrip = try subscription.nextMessage(1000);
try std.testing.expectEqualStrings(
message_data,
roundtrip.getData() orelse return error.TestUnexpectedResult,
);
try std.testing.expect(subscription.isValid() == false);
}
{
const subscription = try connection.queueSubscribeSync(message_subject, "queuegroup");
defer subscription.destroy();
try subscription.drain();
try subscription.waitForDrainCompletion(1000);
_ = subscription.drainCompletionStatus();
}
{
const subscription = try connection.subscribeSync(message_subject);
defer subscription.destroy();
try subscription.drain();
try subscription.waitForDrainCompletion(1000);
_ = subscription.drainCompletionStatus();
}
{
const subscription = try connection.subscribeSync(message_subject);
defer subscription.destroy();
try subscription.drainTimeout(1000);
try subscription.waitForDrainCompletion(1000);
}
}
fn onMessage(
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
userdata: *const u32,
connection: *nats.Connection,
subscription: *nats.Subscription,
message: *nats.Message,
) void {
_ = subscription;
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
_ = userdata;
if (message.getReply()) |reply| {
connection.publish(reply, "greetings") catch @panic("OH NO");
} else @panic("HOW");
}
test "nats.Subscription (async)" {
var server = try util.TestServer.launch(.{});
defer server.stop();
try nats.init(nats.default_spin_count);
defer nats.deinit();
const connection = try nats.Connection.connectTo(server.url);
defer connection.destroy();
const message_subject: [:0]const u8 = "hello";
const message_reply: [:0]const u8 = "reply";
const message_data: [:0]const u8 = "world";
const message = try nats.Message.create(message_subject, message_reply, message_data);
defer message.destroy();
{
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
const count: u32 = 0;
const subscription = try connection.subscribe(*const u32, message_subject, onMessage, &count);
defer subscription.destroy();
const response = try connection.requestMessage(message, 1000);
try std.testing.expectEqualStrings(
"greetings",
response.getData() orelse return error.TestUnexpectedResult,
);
}
{
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
const count: u32 = 0;
const subscription = try connection.subscribeTimeout(
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
*const u32,
message_subject,
1000,
onMessage,
&count,
);
defer subscription.destroy();
const response = try connection.requestMessage(message, 1000);
try std.testing.expectEqualStrings(
"greetings",
response.getData() orelse return error.TestUnexpectedResult,
);
}
{
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
const count: u32 = 0;
const subscription = try connection.queueSubscribe(
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
*const u32,
message_subject,
"queuegroup",
onMessage,
&count,
);
defer subscription.destroy();
const response = try connection.requestMessage(message, 1000);
try std.testing.expectEqualStrings(
"greetings",
response.getData() orelse return error.TestUnexpectedResult,
);
}
{
var count: u32 = 0;
const subscription = try connection.queueSubscribeTimeout(
all: allow passing more types of pointers as callback userdata By performing more pointer casting gymnastics, additional types of pointer can be supported. For example, now const qualified pointers can be passed through thanks to the use of constCast. Also, having explicit ptrCast allows nested pointers (e.g. a pointer to a slice, such as `*[]const u8`) to be passed as userdata as well (the compiler refuses to coerce a pointer to a pointer to `?*anyopaque` for some reason, I guess because maybe it's ambiguous somehow?) Hopefully this extra casting does not appreciably reduce the compiler's ability to catch real bugs (for example, on a 64-bit machine, ptrCast can convert a *u64 into a **u64 because there is no alignment change). Also, the `volatile` pointer specifier is still not supported. `allowzero` pointers probably also have a problem. Those are both extreme edge cases, however. This was intended to work before but did not due to an oversight. Specifically, because the userdata pointers are stored as ?*anyopaque, which does *not* have the const qualifier, they must have their const qualifiers also removed. This is safe because the thunk guarantees that the consumer code never sees the non-const version of the pointer, and the nats library itself does nothing except pass the pointer through to the user callback. The tests have been updated to ensure this case works. The examples still use a mutable userdata pointer to show that that case also works. More tests could be added for the sake of increased rigor, but I don't think it adds much.
2024-04-06 15:07:13 -07:00
*const u32,
message_subject,
"queuegroup",
1000,
onMessage,
&count,
);
defer subscription.destroy();
const response = try connection.requestMessage(message, 1000);
try std.testing.expectEqualStrings(
"greetings",
response.getData() orelse return error.TestUnexpectedResult,
);
}
}