2025-02-25 22:40:03 +01:00
|
|
|
import type { PeerId } from "@libp2p/interface";
|
2025-07-02 23:03:47 +02:00
|
|
|
import {
|
2025-09-04 15:52:37 -07:00
|
|
|
type LightPushCoreResult,
|
|
|
|
|
LightPushError,
|
2025-07-02 23:03:47 +02:00
|
|
|
ProtocolError,
|
|
|
|
|
Protocols
|
|
|
|
|
} from "@waku/interfaces";
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
import { createRoutingInfo } from "@waku/utils";
|
2025-02-25 22:40:03 +01:00
|
|
|
import { expect } from "chai";
|
|
|
|
|
import sinon from "sinon";
|
|
|
|
|
|
|
|
|
|
import { PeerManager } from "../peer_manager/index.js";
|
|
|
|
|
|
|
|
|
|
import { RetryManager, ScheduledTask } from "./retry_manager.js";
|
|
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
const TestRoutingInfo = createRoutingInfo(
|
|
|
|
|
{ clusterId: 0 },
|
|
|
|
|
{ pubsubTopic: "/waku/2/rs/0/0" }
|
|
|
|
|
);
|
|
|
|
|
|
2025-02-25 22:40:03 +01:00
|
|
|
describe("RetryManager", () => {
|
|
|
|
|
let retryManager: RetryManager;
|
|
|
|
|
let peerManager: PeerManager;
|
|
|
|
|
let mockPeerId: PeerId;
|
|
|
|
|
let clock: sinon.SinonFakeTimers;
|
|
|
|
|
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
clock = sinon.useFakeTimers();
|
|
|
|
|
|
|
|
|
|
mockPeerId = { toString: () => "test-peer-id" } as PeerId;
|
|
|
|
|
peerManager = {
|
|
|
|
|
getPeers: () => [mockPeerId],
|
2025-07-02 23:03:47 +02:00
|
|
|
renewPeer: sinon.spy(),
|
2025-02-25 22:40:03 +01:00
|
|
|
start: sinon.spy(),
|
|
|
|
|
stop: sinon.spy()
|
|
|
|
|
} as unknown as PeerManager;
|
|
|
|
|
|
|
|
|
|
retryManager = new RetryManager({
|
|
|
|
|
peerManager,
|
|
|
|
|
retryIntervalMs: 100
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
afterEach(() => {
|
|
|
|
|
clock.restore();
|
|
|
|
|
retryManager.stop();
|
|
|
|
|
sinon.restore();
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should start and stop interval correctly", () => {
|
|
|
|
|
const setIntervalSpy = sinon.spy(global, "setInterval");
|
|
|
|
|
const clearIntervalSpy = sinon.spy(global, "clearInterval");
|
|
|
|
|
|
|
|
|
|
retryManager.start();
|
|
|
|
|
expect(setIntervalSpy.calledOnce).to.be.true;
|
|
|
|
|
|
|
|
|
|
retryManager.stop();
|
|
|
|
|
expect(clearIntervalSpy.calledOnce).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should process tasks in queue", async () => {
|
|
|
|
|
const successCallback = sinon.spy(
|
2025-09-04 15:52:37 -07:00
|
|
|
async (peerId: PeerId): Promise<LightPushCoreResult> => ({
|
2025-02-25 22:40:03 +01:00
|
|
|
success: peerId,
|
|
|
|
|
failure: null
|
|
|
|
|
})
|
|
|
|
|
);
|
|
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
retryManager.push(successCallback, 3, TestRoutingInfo);
|
2025-02-25 22:40:03 +01:00
|
|
|
retryManager.start();
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
await clock.tickAsync(200);
|
|
|
|
|
retryManager.stop();
|
2025-02-25 22:40:03 +01:00
|
|
|
|
|
|
|
|
expect(successCallback.calledOnce, "called").to.be.true;
|
|
|
|
|
expect(successCallback.calledWith(mockPeerId), "called with peer").to.be
|
|
|
|
|
.true;
|
|
|
|
|
});
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
it("should requeue task if no peer is available", async () => {
|
|
|
|
|
(peerManager as any).getPeers = () => [];
|
|
|
|
|
const callback = sinon.spy();
|
|
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
retryManager.push(callback, 2, TestRoutingInfo);
|
2025-07-02 23:03:47 +02:00
|
|
|
retryManager.start();
|
|
|
|
|
|
|
|
|
|
const queue = (retryManager as any)["queue"] as ScheduledTask[];
|
|
|
|
|
expect(queue.length).to.equal(1);
|
|
|
|
|
|
|
|
|
|
await clock.tickAsync(200);
|
|
|
|
|
retryManager.stop();
|
|
|
|
|
|
|
|
|
|
expect(callback.called).to.be.false;
|
|
|
|
|
expect(queue.length).to.equal(1);
|
|
|
|
|
expect(queue[0].maxAttempts).to.equal(1);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should not requeue if maxAttempts is exhausted and no peer is available", async () => {
|
|
|
|
|
(peerManager as any).getPeers = () => [];
|
|
|
|
|
const callback = sinon.spy();
|
|
|
|
|
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
retryManager.push(callback, 1, TestRoutingInfo);
|
2025-07-02 23:03:47 +02:00
|
|
|
retryManager.start();
|
|
|
|
|
const queue = (retryManager as any)["queue"] as ScheduledTask[];
|
|
|
|
|
expect(queue.length).to.equal(1);
|
|
|
|
|
|
|
|
|
|
await clock.tickAsync(500);
|
|
|
|
|
retryManager.stop();
|
|
|
|
|
|
|
|
|
|
expect(callback.called).to.be.false;
|
|
|
|
|
expect(queue.length).to.equal(0);
|
|
|
|
|
});
|
|
|
|
|
|
2025-02-25 22:40:03 +01:00
|
|
|
it("should retry failed tasks", async () => {
|
|
|
|
|
const failingCallback = sinon.spy(
|
2025-09-04 15:52:37 -07:00
|
|
|
async (): Promise<LightPushCoreResult> => ({
|
2025-02-25 22:40:03 +01:00
|
|
|
success: null,
|
2025-09-04 15:52:37 -07:00
|
|
|
failure: { error: LightPushError.GENERIC_FAIL }
|
2025-02-25 22:40:03 +01:00
|
|
|
})
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const queue = (retryManager as any)["queue"] as ScheduledTask[];
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
const task = {
|
|
|
|
|
callback: failingCallback,
|
|
|
|
|
maxAttempts: 2,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
routingInfo: TestRoutingInfo
|
2025-07-02 23:03:47 +02:00
|
|
|
};
|
2025-02-25 22:40:03 +01:00
|
|
|
await (retryManager as any)["taskExecutor"](task);
|
|
|
|
|
|
|
|
|
|
expect(failingCallback.calledOnce, "executed callback").to.be.true;
|
|
|
|
|
expect(
|
|
|
|
|
queue.some((t) => t.maxAttempts === 1),
|
|
|
|
|
"task attempt decreased"
|
|
|
|
|
).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should request peer renewal on specific errors", async () => {
|
2025-09-04 15:52:37 -07:00
|
|
|
const errorCallback = sinon.spy(async (): Promise<LightPushCoreResult> => {
|
2025-02-25 22:40:03 +01:00
|
|
|
throw new Error(ProtocolError.NO_PEER_AVAILABLE);
|
|
|
|
|
});
|
|
|
|
|
|
2025-07-21 15:02:26 +10:00
|
|
|
await (retryManager as RetryManager)["taskExecutor"]({
|
2025-02-25 22:40:03 +01:00
|
|
|
callback: errorCallback,
|
2025-07-02 23:03:47 +02:00
|
|
|
maxAttempts: 1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
routingInfo: TestRoutingInfo
|
2025-02-25 22:40:03 +01:00
|
|
|
});
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
expect((peerManager.renewPeer as sinon.SinonSpy).calledOnce).to.be.true;
|
|
|
|
|
expect(
|
|
|
|
|
(peerManager.renewPeer as sinon.SinonSpy).calledWith(mockPeerId, {
|
|
|
|
|
protocol: Protocols.LightPush,
|
2025-07-21 15:02:26 +10:00
|
|
|
pubsubTopic: TestRoutingInfo.pubsubTopic
|
2025-07-02 23:03:47 +02:00
|
|
|
})
|
|
|
|
|
).to.be.true;
|
2025-02-25 22:40:03 +01:00
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should handle task timeouts", async () => {
|
2025-09-04 15:52:37 -07:00
|
|
|
const slowCallback = sinon.spy(async (): Promise<LightPushCoreResult> => {
|
2025-02-25 22:40:03 +01:00
|
|
|
await new Promise((resolve) => setTimeout(resolve, 15000));
|
|
|
|
|
return { success: mockPeerId, failure: null };
|
|
|
|
|
});
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
const task = {
|
|
|
|
|
callback: slowCallback,
|
|
|
|
|
maxAttempts: 1,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
routingInfo: TestRoutingInfo
|
2025-07-02 23:03:47 +02:00
|
|
|
};
|
2025-02-25 22:40:03 +01:00
|
|
|
const executionPromise = (retryManager as any)["taskExecutor"](task);
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
await clock.tickAsync(11000);
|
2025-02-25 22:40:03 +01:00
|
|
|
await executionPromise;
|
|
|
|
|
|
|
|
|
|
expect(slowCallback.calledOnce).to.be.true;
|
|
|
|
|
});
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
it("should not execute task if max attempts is 0", async () => {
|
2025-09-04 15:52:37 -07:00
|
|
|
const failingCallback = sinon.spy(
|
|
|
|
|
async (): Promise<LightPushCoreResult> => {
|
|
|
|
|
throw new Error("test error" as any);
|
|
|
|
|
}
|
|
|
|
|
);
|
2025-02-25 22:40:03 +01:00
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
const task = {
|
|
|
|
|
callback: failingCallback,
|
|
|
|
|
maxAttempts: 0,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
routingInfo: TestRoutingInfo
|
2025-07-02 23:03:47 +02:00
|
|
|
};
|
2025-02-25 22:40:03 +01:00
|
|
|
await (retryManager as any)["taskExecutor"](task);
|
|
|
|
|
|
2025-07-02 23:03:47 +02:00
|
|
|
expect(failingCallback.called).to.be.false;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should not retry if at least one success", async () => {
|
|
|
|
|
let called = 0;
|
|
|
|
|
(peerManager as any).getPeers = () => [mockPeerId];
|
|
|
|
|
const successCallback = sinon.stub().callsFake(() => {
|
|
|
|
|
called++;
|
|
|
|
|
if (called === 1) retryManager.stop();
|
|
|
|
|
return Promise.resolve({ success: mockPeerId, failure: null });
|
|
|
|
|
});
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
retryManager.push(successCallback, 2, TestRoutingInfo);
|
2025-07-02 23:03:47 +02:00
|
|
|
retryManager.start();
|
|
|
|
|
await clock.tickAsync(500);
|
|
|
|
|
expect(called).to.equal(1);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("should retry if all attempts fail", async () => {
|
|
|
|
|
let called = 0;
|
|
|
|
|
(peerManager as any).getPeers = () => [mockPeerId];
|
|
|
|
|
const failCallback = sinon.stub().callsFake(() => {
|
|
|
|
|
called++;
|
|
|
|
|
return Promise.resolve({
|
|
|
|
|
success: null,
|
2025-09-04 15:52:37 -07:00
|
|
|
failure: { error: LightPushError.GENERIC_FAIL }
|
2025-07-02 23:03:47 +02:00
|
|
|
});
|
|
|
|
|
});
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
retryManager.push(failCallback, 2, TestRoutingInfo);
|
2025-07-02 23:03:47 +02:00
|
|
|
retryManager.start();
|
|
|
|
|
await clock.tickAsync(1000);
|
|
|
|
|
retryManager.stop();
|
|
|
|
|
expect(called).to.be.greaterThan(1);
|
|
|
|
|
const queue = (retryManager as any)["queue"] as ScheduledTask[];
|
|
|
|
|
expect(queue.length).to.equal(0);
|
2025-02-25 22:40:03 +01:00
|
|
|
});
|
|
|
|
|
});
|