bug: subscription not found if we start the node with the --pubsub-topic and we attempt to retrieve messages

[fbarbu15]

Describe the bug
If we start the node with --pubsub-topic=/waku/2/rs/0/0 and we try to query messages with relay/v1/messages based on that content topic we will get no subscription found for pubsubTopic

To Reproduce

docker run -i -t -p 42306:42306 -p 42307:42307 -p 42308:42308 -p 42309:42309 -p 42310:42310 harbor.status.im/wakuorg/nwaku:latest --listen-address=0.0.0.0 --rest=true --rest-admin=true --websocket-support=true --log-level=TRACE --rest-relay-cache-capacity=100 --websocket-port=42308 --rest-port=42306 --tcp-port=42307 --discv5-udp-port=42309 --rest-address=0.0.0.0 --nat=extip:172.18.129.28 --peer-exchange=true --discv5-discovery=true --cluster-id=0 --metrics-server=true --metrics-server-address=0.0.0.0 --metrics-server-port=42310 --metrics-logging=true --relay=true --nodekey=30348dd51465150e04a5d9d932c72864c8967f806cce60b5d26afeca1e77eb68 --pubsub-topic=/waku/2/rs/0/0
docker network connect --ip 172.18.129.28 waku 9f62df9cdde05f51e3899201a99372f210b72981bb15f997c519798ee7b4ccfc

docker run -i -t -p 7682:7682 -p 7683:7683 -p 7684:7684 -p 7685:7685 -p 7686:7686 harbor.status.im/wakuorg/go-waku:latest --listen-address=0.0.0.0 --rest=true --rest-admin=true --websocket-support=true --log-level=DEBUG --rest-relay-cache-capacity=100 --websocket-port=7684 --rest-port=7682 --tcp-port=7683 --discv5-udp-port=7685 --rest-address=0.0.0.0 --nat=extip:172.18.80.140 --peer-exchange=true --discv5-discovery=true --cluster-id=0 --min-relay-peers-to-publish=1 --rest-filter-cache-capacity=50 --relay=true --discv5-bootstrap-node=enr:-LO4QO3oEq4W0BRZ3gWRSekNCMgsN5C3VJhVUVRHy6HPeieELsJ97aCLKrNPGVVV5RgXZcNdvI789MwVil2aXN-3s9UBgmlkgnY0gmlwhKwSgRyKbXVsdGlhZGRyc4wACgSsEoEcBqVE3QOCcnOFAAABAACJc2VjcDI1NmsxoQM3Tqpf5eFn4Jztm4gB0Y0JVSJyxyZsW8QR-QU5DZb-PYN0Y3CCpUODdWRwgqVFhXdha3UyAQ --pubsub-topic=/waku/2/rs/0/0
docker network connect --ip 172.18.80.140 waku 492071bbe9bd8cfdde03af71d7cd8f42d74e8c0faccfa80cc44e5a6e79a4597b

curl -v -X POST "http://127.0.0.1:42306/relay/v1/messages/%2Fwaku%2F2%2Frs%2F0%2F0" -H "Content-Type: application/json" -d '{"payload": "U2hhcmRpbmcgd29ya3MhIQ==", "contentTopic": "/toychat/2/huilong/proto", "timestamp": '$(date +%s%N)'}'
curl -v -X GET "http://127.0.0.1:7682/relay/v1/messages/%2Fwaku%2F2%2Frs%2F0%2F0" -H "Content-Type: application/json" -d 'None'
ERROR    src.node.api_clients.base_client:base_client.py:17 HTTP error occurred: 404 Client Error: Not Found for url: http://127.0.0.1:7682/relay/v1/messages/%2Fwaku%2F2%2Frs%2F0%2F0. Response content: b'no subscription found for pubsubTopic'

go-waku version/commit hash

go-waku latest

Additional context
Same thing happens if I use different cluster id and content topics ex --cluster-id=2 and --pubsub-topic=/waku/2/rs/2/0

If we do a subscribe request before checking messages it will work but I would expect it to work without it, because it should subscribe, like on nwaku, to the pubsub-topic from the config
curl -v -X POST "http://127.0.0.1:7682/relay/v1/subscriptions" -H "Content-Type: application/json" -d '["/waku/2/rs/0/0"]'
Uploading logs_docker.zip…

[chaitanyaprem]

I remember changing this behaviour as part of REST API changes at some point.
The idea was that just because i am passing --pubsub-topic as an argument to my node doesn't mean i am interested in receiving the messages in the app layer. It could just mean that my node wants to support relaying messages for that pubsubTopic in the network.

Hence i had modified the behvaiour to only receive messages if someone subscribes explicitly via REST API for a pubsubTopic.
In-fact this should be the right behaviour even in the nwaku node. cc @waku-org/nwaku-developers .

Otherwise, for every node that is running supporting various pubsubTopics for relay (e.g in TWN each node specifies all pubsubTopics it is supporting which is 8 shards), messages are being un-necessarily sent up to the messageCache and then discarded because there is no consumer of these messages.
If a user wants to consume relay messages, then let them subscribe from the REST API specifically for a pubsubTopic.

This segregates the functionality of a node's ability to just relay messages for a pubsubTopic (by specifying it in argument via --pubsub-topic) vs a node that wants to consume messages on a pubsubTopic (by subscribing via REST API).
This is inline with pubsub terminology of not having a necessity to subscribe to a pubsubTopic for just relaying messages.

[chaitanyaprem]

So, to summarize after starting the node if you send a REST API request to subscribe to pubsubTopic then you should be able to fetch messages relayed on that topic via GET messages API.

[fbarbu15]

Thanks for the explanation, it makes sense indeed to work this way.

[SionoiS]

i had modified the behvaiour to only receive messages if someone subscribes explicitly via REST API for a pubsubTopic.
In-fact this should be the right behaviour even in the nwaku node. cc @waku-org/nwaku-developers .

I agree that would be better. Use the config for shards and REST for app lvl stuff.

[fbarbu15]

Thanks, I've opened this change request on nwaku side