fix: debounceTime with asapScheduler deadlock because of nested calls

[yuri-apanasik]

Description:

Related to (#7205)

BREAKING CHANGE:

Related issue (if exists):

[benlesh]

Hi, @yuri-apanasik, thank you for your contribution. Please add a test and confirm that the test is broken in master prior to changing any code.

[yuri-apanasik]

Hi @benlesh, as a wrote here (#7207) I have a problem with test, behavior is different in testing environment and runtime. Do you have any ideas why this difference could be?

[LcsGa]

Suggested change

	action = action || actions.shift()!;
	action = action ?? actions.shift()!;

[pmoleri]

Hi @yuri-apanasik
I think that the correct code should be analogous to this patch:
https://github.com/ReactiveX/rxjs/pull/7444/files#diff-64da125812f733a97ec0d18250db7664156743309052001c7a5eeaf2109a822b
With action.id taking precedence and _scheduled only cleaned when it's its case.

Hi @benlesh, as a wrote here (#7207) I have a problem with test, behavior is different in testing environment and runtime. Do you have any ideas why this difference could be?

In my PR I also noticed some asap tests that were failing until I changed the way in which fakeTimers were registered.
You could check if that fixes (or make fail) your tests too,

[yuri-apanasik]

Hi @pmoleri , to tell the truth I even forgot about this PR... As I remember and as I can see in the code, global logic with both patches (your or mine) will be the same. I would say we can wait until at least one PR will be merged by maintainers and adjust another PR so code in both animationFrame/asap schedulers is consistent.
Thank you for the hint with tests. I'll try to fix them on the weekend.

[pmoleri]

@yuri-apanasik

global logic with both patches (your or mine) will be the same

The code communicates different intents, although, in practice it might end up being equivalent because of specifics about asapScheduler.

In your code _scheduled is taking precedence as flushid and is always clearing the _scheduled, even if the dispatched action was in the parameter with a different id.
This has 2 consequences:

• It may flush unrelated actions
• It will clear the _scheduled when it's not its turn.

In asapScheduler, in my experience _scheduled actions always get flushed before any other delayed action, so those consequences don't have any negative impact. In animationFrameScheduler it's critical, because delayed action can indeed happen before _scheduled ones having very negative consequences.