fix: handle all empty responses in filter

[vpavlin]

Problem

I got an exception about undefined res - seems

waku:filter:v2 Error pinging:  +11ms TypeError: res[0] is undefined

Seems like this d049ebb only fixed subscribe and ping and unsubscribe still needed the check

Solution

Add check and throw an error for empty response

Notes

• Resolves
• Related to

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
Waku core	83.85 KB (0%)	1.7 s (0%)	375 ms (+33.47% 🔺)	2.1 s
Waku Simple Light Node	264.23 KB (+0.02% 🔺)	5.3 s (+0.02% 🔺)	736 ms (+11.36% 🔺)	6.1 s
ECIES encryption	79.46 KB (0%)	1.6 s (0%)	511 ms (+24.09% 🔺)	2.2 s
Symmetric encryption	79.47 KB (0%)	1.6 s (0%)	303 ms (-28.98% 🔽)	1.9 s
DNS discovery	111.22 KB (0%)	2.3 s (0%)	487 ms (-0.91% 🔽)	2.8 s
Privacy preserving protocols	131.77 KB (0%)	2.7 s (0%)	498 ms (-11.14% 🔽)	3.2 s
Light protocols	81.59 KB (+0.02% 🔺)	1.7 s (+0.02% 🔺)	403 ms (+19.94% 🔺)	2.1 s
History retrieval protocols	80.54 KB (0%)	1.7 s (0%)	330 ms (-22.22% 🔽)	2 s
Deterministic Message Hashing	5.65 KB (0%)	113 ms (0%)	61 ms (-10.57% 🔽)	174 ms

[fryorcraken]

LGTM but I think the API should be more consistent.

We are using throwing Error here whereas for light push we return error codes. We decide whether it's one or the other across the APIs.

cc @waku-org/js-waku-developers

[danisharora099]

LGTM but I think the API should be more consistent.

We are using throwing Error here whereas for light push we return error codes. We decide whether it's one or the other across the APIs.

cc @waku-org/js-waku-developers

IMO, returning error codes is an approach we should follow through the codebase.

[weboko]

Agree with error codes approach for recoverable failures. I think for failures that prevent the flow - we might still try throwing.

[fryorcraken]

Agree with error codes approach for recoverable failures. I think for failures that prevent the flow - we might still try throwing.

#1694