helium / blockchain-http

An http API for the helium blockchain database
https://helium.com
Apache License 2.0
47 stars 18 forks source link

/activity endpoint not returning expected results #377

Closed khag7 closed 2 years ago

khag7 commented 2 years ago

I'm new here so maybe I'm misunderstanding something, but I think I found an issue with the /activity endpoint not returning up-to-date results in some cases.

I believe these two URL's should return the same response: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types=

To take it a step further... This URL: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types=rewards_v1%2Crewards_v2%2Crewards_v3 returns {"data":[]} But if I ask for just rewards_v1 or rewards_v2 or rewards_v3 individually I am getting back activity data: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types=rewards_v2

Is this a caching issue or something worse?

madninja commented 2 years ago

I'm new here so maybe I'm misunderstanding something, but I think I found an issue with the /activity endpoint not returning up-to-date results in some cases.

I believe these two URL's should return the same response: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types='

Could you provide examples where this is not the case please? I can't reproduce this issue.

To take it a step further... This URL: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types=rewards_v1%2Crewards_v2%2Crewards_v3 returns {"data":[]} But if I ask for just rewards_v1 or rewards_v2 or rewards_v3 individually I am getting back activity data: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types=rewards_v2

Is this a caching issue or something worse?

No, the latter issue you're having is that you're likely passing in an unsupported filter_type.. rewards_v3 does not exist

khag7 commented 2 years ago

Could you provide examples where this is not the case please? I can't reproduce this issue.

These two URL's return the same response, as expected: https://helium-api.stakejoy.com/v1/hotspots/112hJaYM8vTRBagNQQcs71zXUoivaTCmpZU4wKpccQMAV4WmdR4K/activity?filter_types= https://helium-api.stakejoy.com/v1/hotspots/112hJaYM8vTRBagNQQcs71zXUoivaTCmpZU4wKpccQMAV4WmdR4K/activity

If you replace the hotspot ID with any other hotspot ID you're almost certain to get the same result from both URLs. I just happen to have found one hotspot ID that isn't returning the correct results if the filter_types url parameter is present.

No, the latter issue you're having is that you're likely passing in an unsupported filter_type.. rewards_v3 does not exist

The helium explorer website (explorer.helium.com) is making calls to the API using rewards_v3 as one of the filter types. See screenshot below from chrome devtools showing that. image Also, here is an example of a URL that works just fine even if rewards_v3 is included: https://helium-api.stakejoy.com/v1/hotspots/112hJaYM8vTRBagNQQcs71zXUoivaTCmpZU4wKpccQMAV4WmdR4K/activity?filter_types=rewards_v1%2Crewards_v2%2Crewards_v3 That returns the same result with or without rewards_v3 present in the URL: https://helium-api.stakejoy.com/v1/hotspots/112hJaYM8vTRBagNQQcs71zXUoivaTCmpZU4wKpccQMAV4WmdR4K/activity?filter_types=rewards_v1%2Crewards_v2

Something strange is going on but it only seems to be affecting that one hotspot ID (there's likely others, but the majority of hotspot ID's I've checked against return the expected results)

madninja commented 2 years ago

Can you see if the issue has "magically disappeared"?

This URL: https://helium-api.stakejoy.com/v1/hotspots/11RUc13Hp5NZKB4fiFRqQRRhqufWnMp85ZXERbmTbmjLJ5MpMgE/activity?filter_types=rewards_v1%2Crewards_v2%2Crewards_v3 returns {"data":[]}

When I fetch that URL I get back empty data and a cursor, which is as expected

khag7 commented 2 years ago

The issue has magically disappeared, everything is working as expected now.

I suppose I should've taken screenshots of the actual responses. Because I have no screenshots attached, nobody will be able to confirm that the issue actually existed. But if someone wants to try to reproduce this in the future, it won't be easy, as I was only ever able to find just one hotspot that showed this issue.

madninja commented 2 years ago

Oh I believe you.. The working theory is that there's some edge condition where 100 block alignment fails somehow. I just can't find a good way to reproduce it and it usually disappears within a block or two

khag7 commented 2 years ago

That's got to be frustrating to diagnose. For me, the only negative impact was that I couldn't see my activity on the helium explorer website. I "fixed" it from my end by installing a plugin for chrome that modified all outgoing requests to the helium api. I just tacked on a nonsense url parameter at the end of the request url (&a=b) and that was enough to force the api to give the correct results. That's what makes me think its a caching issue. Why would adding nonsense url parameters suddenly make it work?

madninja commented 2 years ago

That's got to be frustrating to diagnose. For me, the only negative impact was that I couldn't see my activity on the helium explorer website. I "fixed" it from my end by installing a plugin for chrome that modified all outgoing requests to the helium api. I just tacked on a nonsense url parameter at the end of the request url (&a=b) and that was enough to force the api to give the correct results. That's what makes me think its a caching issue. Why would adding nonsense url parameters suddenly make it work?

I think I have a lead on what's gong on.. In your case adding an extra parameter avoids you hitting the fastly cached result. I'll get a fix up soon