Debouncing doesn't seem to be implemented in a useful way

[diesieben07]

The relatively new debounce option on jobs seems to cover my use-case exactly. I want to run an export job whenever a piece of data changes. When the data changes rapidly, I want to only export it once.

However, during the "debounce TTL" new jobs with the same debounce ID will be ignored entirely. This causes the following problem:

• Change Data from A to B, job triggers immediately ("B" is exported)
• Change Data from B to C within debounce TTL, job does not trigger at all

Now the exported data is out of date.

What I would expect to happen is:

• Change Data from A to B, job is pending (delayed by debounce TTL)
• Change Data from B to C within debounce TTL, pending Job's delay is updated so it now runs [debounce TTL] after this change
• Eventually debounce TTL passes after the last change, job runs, latest data is exported.

How to achieve this desired behavior?

[roggervalf]

hi @diesieben07, you also can use delay along side with your ttl in this case. Same delay value as your ttl if you don't want to have eventual consistency.

[diesieben07]

Thank you for your reply, however I am a bit confused. I think what you mean is something like setting debounce-ttl to 10_000 and delay to 11_000. Then for the 10_000 no new tasks will be scheduled, but at 11_000 the delayed one will be ran.
If I understand this right, this will be sort of like a throttling (at most one every 10_000ms), right? I think that would be acceptable, even though it is not what I was originally planning to have.

Same delay value as your ttl if you don't want to have eventual consistency.

This also confused me a bit, I specifically do want eventual consistency. Once the mutations have settled, I want the export to run again so that the final, settled data is exported.

[roggervalf]

hey, so there are some cases to consider:

• debounce ttl without delay i.e 10_000, means that any new job with same debounce id will be ignore in that period. Your first job that was added in this period will be processed as soon as one worker picked it. If this job completes before this period, for the remaining time, you will ignore other jobs with same debounce id.
• debounce ttl with delay (same value) i.e 10_000, means that this first job will be added as a delayed one. In this period other jobs will be ignored, but after that time job will be move to wait and be ready to be processed by a worker. Also while this job is in wait state or active, another job with same debounce id can be added (you can always add these jobs with same delay and ttl config).
• In case you want also to ignore jobs while this first job is in active state (not completed), use extended mode (no ttl).

[diesieben07]

Thank you for the clarification. I understood it correctly then, debounce ttl plus a delay effectively becomes throttle (run the job at most once every 10 seconds). This works for me, however it isn't truly what I wanted.

What I wanted was that the job does not run while the mutations are still coming in, instead it runs once at the end.