Guard samples stale data from combined store

[alpatovdanila]

What is the current behavior:
Guard passes stale data from combined store to effect.

Please provide the steps to reproduce and if possible a minimal demo of the problem via https://share.effector.dev, https://codesandbox.io or similar
https://share.effector.dev/jSQ3WPPg

What is the expected behavior:
I am expecting actual state of $requestData store to be passed to target effect

Which versions of effector packages, and which browser and OS are affected by this issue? Did this work in previous versions of effector?:
Bug occurs on 22.1.2 version of Effector

[zerobias]

Agree, this should work in the same way

[MichaelShipitsyn]

It seems that the problem is not in guard. I think the problem is in calculation priority of the clock fn parameter in sample - https://share.effector.dev/MtzNQ2Gx

[zerobias]

@MichaelShipitsyn yes, you right

The more I think about it, the more issues I find. The main question is whether the clock without source should have the same priority as the source in the usual case?

[AlexandrHoroshih]

Weird enough, but wrapping clock in sample into another sample solves the issue 🤔
And making that sample wrapper greedy recreates the bug: https://share.effector.dev/mc4cQ01f

So isn't the problem actually in sample's clock batching mechanism? Looks like, in this situation, sample takes first triggered value of the clock instead of the last one

Another question i see is why there are two combine-ed store update calls?
First of those calls is the one with stale data, but i would expect only one call there 🤔

Changing that first sample to greedy one (here) or changing it to basic .on (there) fixes the issue because there is only one update of combined store - without any stale data 🤔

Doing the same change with the first reproduce also fixes the result: https://share.effector.dev/LWWbv7qt - no combine updates with stale data, no bug

[zerobias]

@AlexandrHoroshih big thanks for deep investigation, I found an issue using your examples 👍

Yes, the bug was in implementation of sample: in case with source store, the first value of clock was used instead of last one

I will publish a fix during this week

[zerobias]

And as for multiple combine updates - it happens because $filterValues is updated strictly after $selectedCities → $requestData update chain. Look at ordering snapshots

[AlexandrHoroshih]

Always glad to help 🤘

it happens because $filterValues is updated strictly after $selectedCities → $requestData update chain

Yes, i see that, but isn't this an observable glitchy value?

In those examples both dependencies of combined store are changed in the same computation cycle, so i would expect that combine will be updated (or at least call its watchers) only once during this cycle, without calling it on stale data 🤔

I see that this has something to do with sample priority level in this case, because by raising the priority manually (via greedy: true or using .on instead) combine triggered only once and we can no longer observe that stale value 🤔