Remove unnecessary check before sending webhook

[Mygod]

Any thoughts?

[jfberry]

What is the motivation for this? If I recall the original check was put in to stop spamming webhook receivers with non impactful changes (although of course, it could be argued that if we are writing a change to disk perhaps we should be telling receivers)

[Mygod]

Exactly. By the time we hit here, we have already passed the check of hasChangesPokemon?

[jfberry]

@Fabio1988 has been investigating excessive webhook update issues, so will leave this for him

[Fabio1988]

I agree on that, at this point we already write changes to disk / cache. so let the receiver know, we don't need a check here :)

Yeah I saw problems with hundos on map, but not reported to end user. It's quite difficult to monitor that issue... I will let you guys know if I find another one :)

[jfberry]

Only issue is that pvp data is not held in memory, so any subsequent webhooks after the one that first calculates pvp will have the pvp field null. This would require recalculation to complete the field.
The db update takes care not to overwrite the on-disk model.

[Fabio1988]

@Mygod so far this change is good, except that we send webhooks with null as pvp value... We should try to prevent that

[jfberry]

This is caused by the fact that the pvp json is not stored in the in-memory cache. It's usually the last webhook sent (as it is full encounter data and a change that triggers the recalculation).
What sequence causes a transmission after this? I agree these should be minimised as are confusing to receivers

[Fabio1988]

e.g. we encountered the mon and stored pvp in db.. after weather boost change we preserved iv because still same boost. So weather changed from X to Y.. therefore we don't have any pvp value in cache and would send pvp: null :)
So probably a rare edge case

[Fabio1988]

rebased on latest. I think this should be merged. additionally we should find a way how to send pvp value when weather changes and boost is kept.

lgtm

[Fabio1988]

@Fabio1988 has been investigating excessive webhook update issues, so will leave this for him

this was resolved already :)