@VolodLytvynenko, you basically simulated the scenario of a User A being a different timezone with a 1h difference. I wonder if after 1h passed after the CR was accepted if messages would be delivered to User B.

@VolodLytvynenko, you basically simulated the scenario of a User A being a different timezone with a 1h difference. I wonder if after 1h passed after the CR was accepted if messages would be delivered to User B.

Hi @ilmotta no, messages of User A are not delivered at all to User B. I simulated it so:
1.User A goes to settings and manually sets a different time (for example, sets the time -5 minutes from their local time).
2. User A sends a message to User B
3. User A waits 10 minutes

Actual result:

The receiver User B does not receive messages from the sender User A at all, but User A receives messages from User B

Thank you for re-checking and all the steps. I'm bumping this issue in importance. I think this is the kind of bug that can drive users crazy and not come back. I set my clock manually when traveling, for example.

Thank you, @VolodLytvynenko, for creating the issue. I can reproduce it by setting a timestamp in the past.

I am removing myself from this assignment to focus on other tasks and to allow someone with more expertise on the topic to handle the issue.

Some notes from quick testing: Related error (With Timestamp 1 hour in the past in logs):

2025-01-02T04:45:39.881Z	ERROR	common/message.go:185	failed to decode message	{"error": "couldn't decrypt using asymmetric key: ecies: invalid message"}
2025-01-02T04:45:39.881Z	DEBUG	common/filter.go:246	processing message: failed to open	{"message": "0x7c7efe09a360159c9a91d1398d23634a0d9d442ca1632ab325ccf163c455236f", "filter": "8966a48236dc14b7602dc38171a4314f533b8171a44e702e40b808a85141a669"}
2025-01-02T04:45:39.881Z	DEBUG	wakuv2/waku.go:1558	filters did not match	{"envelopeHash": "0x7c7efe09a360159c9a91d1398d23634a0d9d442ca1632ab325ccf163c455236f", "pubsubTopic": "/waku/2/rs/16/32", "contentTopic": "/waku/1/0xf97bd12f/rfc26", "timestamp": 1735788556298473368}

The "filters did not match" message belongs to the processMessage function (link to code).

Removing this from milestone for now as no assignee so far for the issue, moving to 2.34

Memo: If it is not getting done in 2.34, maybe we need to remove it from milestone

There's a validation function on clock, comment it out will fix this issue, let's see what the correct solution will be.