Listener storing identities under proxy rather than wallet address

[franckc]

In some cases the listener seems to be storing data in the Identity table by the proxy rather than the wallet's address.

• @mikeshultz found a couple of such rows in prod DB while running the consistency checker
• @shahthepro was able to reproduce on his local as mentioned in issue #2813

The listener should be using the wallet's address. See this code.

This impacts the payout fraud detection for Origin Rewards as well as the notifications service since both those components rely on looking up identity by wallet address.

[mikeshultz]

I looked further into this and it was only one account. The second was just completely missing.

Did not find a matching record for address 0xb268695f38d7639ac0818412d6d421fa91c9e49a(or proxy 0x0b8ad45f63218571baf76aa5ce154ffbeb84df2a)

So, might be safe to say it was a temporary error, but I'll see if I can see what @shahthepro sees.

@shahthepro, can you provide repro steps? And is it when the relayer is enable or just proxies?

[shahthepro]

@mikeshultz I am not sure how to reproduce this either. I don't have relayer enabled, just proxies. I'll see if it happens again and let you know

[franckc]

FYI, I checked in the prod DB and afaict, there are only 2 rows out of 1,306 in the identity table that use a proxy eth address rather than the wallet address:

import=# select * from identity where eth_address in (select address from proxy); eth_address | first_name | last_name | email | phone | twitter | airbnb | facebook_verified | data | created_at | updated_at | google_verified | country | avatar_url | website | facebook | google | kakao | github | linkedin | wechat --------------------------------------------+------------+-----------+-------+-------+---------+--------+-------------------+---------------------------------------------------------+----------------------------+----------------------------+-----------------+---------+-------------------------------------------------------+---------+----------+--------+-------+--------+----------+-------- 0x4531d2f47145d6fb4542bad1726f2203f1d7de7a | N | P | | | | | f | {"blockInfo": {"logIndex": 51, "blockNumber": 7900539}} | 2019-06-05 08:52:29.325-07 | 2019-06-05 10:27:35.579-07 | f | | ipfs://QmQMmh1K7xQHgFL69uYG6XpEzgtNEEs6yf7VZpa7Gfuy5E | | | | | | | 0x0b8ad45f63218571baf76aa5ce154ffbeb84df2a | Kay | Yoo | | | | | f | {"blockInfo": {"logIndex": 90, "blockNumber": 8030733}} | 2019-06-25 18:51:11.535-07 | 2019-06-25 18:51:11.535-07 | f | | | | | | | | | (2 rows)

=> This issue happens rarely... it did happen on June 25th for Kay's account but I think this was before we rolled out a fix in #2448

[franckc]

Given stats above, lowering to a P2. Let's watch a bit more and if this does not happen again, let's close.

[mikeshultz]

Was going through my assigned issues and curious if this is still happening. It is:

                eth_address                 | email |         created_at         |         updated_at         
--------------------------------------------+-------+----------------------------+----------------------------
 0x4531d2f47145d6fb4542bad1726f2203f1d7de7a |       | 2019-06-05 15:52:29.325+00 | 2019-06-05 17:27:35.579+00
 0x0b8ad45f63218571baf76aa5ce154ffbeb84df2a |       | 2019-06-26 01:51:11.535+00 | 2019-06-26 01:51:11.535+00
 0x95f3961fb56fbb93005b1d1b068c6bdf773406a8 |       | 2019-08-08 06:52:25.924+00 | 2019-08-08 06:56:05.296+00
 0xab3037ecfa8767cd111daf444f9c70ba94d014e8 |       | 2019-09-03 07:51:18.529+00 | 2019-09-03 08:44:02.839+00
 0x049c84eeab0db2b7e1d3d842df29bc013a62a9f0 |       | 2019-09-04 01:31:48.133+00 | 2019-09-04 03:01:06.061+00
 0x61a83129fe6646f6045a1ccb926463345c2c4f49 |       | 2019-09-13 14:40:47.11+00  | 2019-09-13 14:40:47.11+00
(6 rows)

[micahalcorn]

Taking this off of @mikeshultz's plate for now 🍽