Missing stacker for signer

[aryzing]

Follow-up from Discord message.

Describe the bug
During cycle 88,

1. user SP1M21C6066PZ27PSR84P3SM35VD0PFMVTVACCZPN delegated to pool
2. The pool locked the user's funds. See events 55-58.
3. The pool committed the delegated Stacks.

When querying the endpoint /extended/v2/pox/cycles/${cycleNumber}/signers/0x${signerPublicKey}/stackers for cycle 89 and the above user, they're not in any of the paginated lists of results.

The pool's signer public key is 02877ce29ba35458b827a6ea18510b9058ae4c30e2c33d288f2982c13497caec6e

Sequence of events:

Expected behavior
The user should be in the signer's list for cycle 89.

[zone117x]

I'm seeing some revoke-delegate-stx calls from this stacker. Could that explain the problem?

https://api.hiro.so/extended/v1/pox4/stacker/SP1M21C6066PZ27PSR84P3SM35VD0PFMVTVACCZPN

[aryzing]

@zone117x is that API endpoint documented? I can't seem to find it

[aryzing]

@zone117x looked into the revokes: aren't all the revokes immediately followed by a successful delegate-stx from within the same transaction?

[zone117x]

@janniks does anything here stand out to you? I can't tell if there might be some block timing issue?

[janniks]

Looks like the events happen as expected. Unclear why the stacker isn't showing up. Maybe we can search log files if something wasn't ingested 🤔

[zone117x]

@janniks any idea if it's possible to perform RPC map lookups (perhaps with specifying ?tip=<hash> for relevant block heights) to determine if this stacker is in the correct state in pox4? It's not clear to me where the source of this problem is coming from.

[aryzing]

I just remembered that a while back I opened #2022, could it be related?

[aryzing]

Have you had a chance to look into this?