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 {
|
|
|
|
|
ContentTopic,
|
|
|
|
|
type CreateNodeOptions,
|
|
|
|
|
type NetworkConfig,
|
|
|
|
|
Protocols,
|
|
|
|
|
type ShardId
|
|
|
|
|
} from "@waku/interfaces";
|
|
|
|
|
import { createRelayNode, RelayCreateOptions } from "@waku/relay";
|
2024-10-09 00:43:34 +02:00
|
|
|
import { createLightNode, WakuNode } from "@waku/sdk";
|
2024-08-13 05:23:20 +05:30
|
|
|
import {
|
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
|
|
|
createRoutingInfo,
|
|
|
|
|
isAutoSharding,
|
|
|
|
|
isStaticSharding,
|
2024-08-13 05:23:20 +05:30
|
|
|
Logger,
|
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
|
2024-08-13 05:23:20 +05:30
|
|
|
} from "@waku/utils";
|
2024-04-28 11:15:17 +02:00
|
|
|
import { Context } from "mocha";
|
|
|
|
|
|
|
|
|
|
import { NOISE_KEY_1 } from "../constants.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
|
|
|
import { Args } from "../types.js";
|
2024-04-28 11:15:17 +02:00
|
|
|
import { makeLogFileName } from "../utils/index.js";
|
|
|
|
|
|
|
|
|
|
import { ServiceNode } from "./service_node.js";
|
|
|
|
|
|
|
|
|
|
export const log = new Logger("test:runNodes");
|
|
|
|
|
|
2025-05-30 16:27:00 +05:30
|
|
|
export const DEFAULT_DISCOVERIES_ENABLED = {
|
feat!: re-architect connection manager (#2445)
* remove public pubsub field and redundant util
* add hangUp and improve dial operations, improve keepAliveManager and remove unused method, move utils and add tests
* improve public dial method to start keep alive checks
* move dial method
* implement discovery dialer
* implement discovery dialer with queue with tests
* add discovery dialer e2e tests, change local discovery log tag, update other tests
* remove comment
* add issue link, remove only
* implement shard reader component
* create evetns module, remove unused connection manager events and related tests
* implement network indicator
* implement connection limiter, change public API of connection manager, implement recovery strategy
* decouple keep alive maanger
* add connection manager js-doc
* refactor keep alive manager, cover with tests
* add tests for connection manager main facade
* add tests for connection limiter
* add e2e tests for connection manager modules
pass js-waku config during test node init
remove dns discovery for js-waku
* restructure dialing tests
* address last e2e tests
* address review
* add logging for main methods
* decouple pure dialer class, update network monitor with specific metrics
* remove console.log
* remove usage of protocols
* update sdk package tests
* add connect await promise
* add debug for e2e tests
* enable only packages tests
* use only one file
* revert debugging
* up interface for netwrok manager
* add logs
* add more logs
* add more logs
* add another logs
* remove .only
* remove log statements
* skip the test with follow up
2025-07-09 21:23:14 +02:00
|
|
|
dns: false,
|
2025-05-30 16:27:00 +05:30
|
|
|
peerExchange: true,
|
feat!: re-architect connection manager (#2445)
* remove public pubsub field and redundant util
* add hangUp and improve dial operations, improve keepAliveManager and remove unused method, move utils and add tests
* improve public dial method to start keep alive checks
* move dial method
* implement discovery dialer
* implement discovery dialer with queue with tests
* add discovery dialer e2e tests, change local discovery log tag, update other tests
* remove comment
* add issue link, remove only
* implement shard reader component
* create evetns module, remove unused connection manager events and related tests
* implement network indicator
* implement connection limiter, change public API of connection manager, implement recovery strategy
* decouple keep alive maanger
* add connection manager js-doc
* refactor keep alive manager, cover with tests
* add tests for connection manager main facade
* add tests for connection limiter
* add e2e tests for connection manager modules
pass js-waku config during test node init
remove dns discovery for js-waku
* restructure dialing tests
* address last e2e tests
* address review
* add logging for main methods
* decouple pure dialer class, update network monitor with specific metrics
* remove console.log
* remove usage of protocols
* update sdk package tests
* add connect await promise
* add debug for e2e tests
* enable only packages tests
* use only one file
* revert debugging
* up interface for netwrok manager
* add logs
* add more logs
* add more logs
* add another logs
* remove .only
* remove log statements
* skip the test with follow up
2025-07-09 21:23:14 +02:00
|
|
|
localPeerCache: false
|
2025-05-30 16:27:00 +05:30
|
|
|
};
|
|
|
|
|
|
2024-04-28 11:15:17 +02:00
|
|
|
type RunNodesOptions = {
|
|
|
|
|
context: Context;
|
2024-08-13 05:23:20 +05:30
|
|
|
networkConfig: NetworkConfig;
|
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
|
|
|
relayShards?: ShardId[]; // Only for static sharding
|
|
|
|
|
contentTopics?: ContentTopic[]; // Only for auto sharding
|
2024-04-28 11:15:17 +02:00
|
|
|
protocols: Protocols[];
|
|
|
|
|
createNode: typeof createLightNode | typeof createRelayNode;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
export async function runNodes<T>(
|
|
|
|
|
options: RunNodesOptions
|
|
|
|
|
): Promise<[ServiceNode, T]> {
|
2024-08-13 05:23:20 +05:30
|
|
|
const { context, networkConfig, createNode, protocols } = options;
|
2024-04-28 11:15:17 +02:00
|
|
|
|
|
|
|
|
const nwaku = new ServiceNode(makeLogFileName(context));
|
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 nwakuArgs: Args = {
|
|
|
|
|
filter: true,
|
|
|
|
|
lightpush: true,
|
|
|
|
|
relay: true,
|
|
|
|
|
store: true,
|
|
|
|
|
clusterId: networkConfig.clusterId
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
const jswakuArgs: CreateNodeOptions = {
|
2024-04-28 11:15:17 +02:00
|
|
|
staticNoiseKey: NOISE_KEY_1,
|
|
|
|
|
libp2p: { addresses: { listen: ["/ip4/0.0.0.0/tcp/0/ws"] } },
|
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
|
|
|
networkConfig,
|
2025-05-30 16:27:00 +05:30
|
|
|
lightPush: { numPeersToUse: 2 },
|
|
|
|
|
discovery: DEFAULT_DISCOVERIES_ENABLED
|
2024-04-28 11:15:17 +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
|
|
|
const routingInfos: RoutingInfo[] = [];
|
|
|
|
|
if (isAutoSharding(networkConfig)) {
|
|
|
|
|
nwakuArgs.numShardsInNetwork = networkConfig.numShardsInCluster;
|
|
|
|
|
nwakuArgs.contentTopic = options.contentTopics ?? [];
|
|
|
|
|
|
|
|
|
|
nwakuArgs.contentTopic.map((ct) =>
|
|
|
|
|
routingInfos.push(createRoutingInfo(networkConfig, { contentTopic: ct }))
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
if (options.relayShards && options.relayShards.length > 0)
|
|
|
|
|
throw "`relayShards` cannot be set for auto-sharding";
|
|
|
|
|
} else if (isStaticSharding(networkConfig) && options.relayShards) {
|
|
|
|
|
const shards = options.relayShards;
|
|
|
|
|
nwakuArgs.shard = shards;
|
2025-07-21 15:54:05 +10:00
|
|
|
nwakuArgs.numShardsInNetwork = 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
|
|
|
|
|
|
|
|
shards.map((shardId) =>
|
|
|
|
|
routingInfos.push(createRoutingInfo(networkConfig, { shardId }))
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
if (options.contentTopics && options.contentTopics.length > 0)
|
|
|
|
|
throw "`contentTopics` cannot be set for static sharding";
|
|
|
|
|
} else {
|
|
|
|
|
throw "Invalid Network Config";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const jswakuRelayCreateOptions: RelayCreateOptions = {
|
|
|
|
|
routingInfos
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
await nwaku.start(nwakuArgs, { retries: 3 });
|
|
|
|
|
|
|
|
|
|
log.info("Starting js waku node with :", JSON.stringify(jswakuArgs));
|
2024-04-28 11:15:17 +02:00
|
|
|
let waku: WakuNode | undefined;
|
|
|
|
|
try {
|
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
|
|
|
waku = (await createNode({
|
|
|
|
|
...jswakuArgs,
|
|
|
|
|
...jswakuRelayCreateOptions
|
|
|
|
|
})) as unknown as WakuNode;
|
2024-04-28 11:15:17 +02:00
|
|
|
await waku.start();
|
|
|
|
|
} catch (error) {
|
|
|
|
|
log.error("jswaku node failed to start:", error);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (waku) {
|
|
|
|
|
await waku.dial(await nwaku.getMultiaddrWithId());
|
2024-10-09 00:43:34 +02:00
|
|
|
await waku.waitForPeers(protocols);
|
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
|
|
|
|
2025-07-19 14:24:30 +10:00
|
|
|
await nwaku.ensureSubscriptions(routingInfos.map((r) => r.pubsubTopic));
|
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
|
|
|
|
2024-04-28 11:15:17 +02:00
|
|
|
return [nwaku, waku as T];
|
|
|
|
|
} else {
|
|
|
|
|
throw new Error("Failed to initialize waku");
|
|
|
|
|
}
|
|
|
|
|
}
|