fix(flags): Enqueue follow up requests without dropping

[neilkakkar]

Changes

My previous PR delayed reloading to the end of the decide request: #791 , and for some reason I copied the wrong queue deletion behaviour instead of fixing it right in that PR 🤦 .

If posthog.identify() was called while we were requesting flags, we should queue this up and not drop it, as otherwise flags will stick around for the anon user rather than the identified one.

Fixes this behaviour, and removes the now-unused resetRequestQueue function

...

Checklist

• Tests for new code (see advice on the tests we use)
• Accounted for the impact of any changes across different browsers

[tiina303]

🤷‍♀️

[github-actions]

Size Change: +160 B (0%)

Total Size: 685 kB

Filename	Size	Change
dist/array.full.js	177 kB	+40 B (0%)
dist/array.js	118 kB	+40 B (0%)
dist/es.js	118 kB	+40 B (0%)
dist/module.js	118 kB	+40 B (0%)

ℹ️ View Unchanged

Filename	Size
dist/recorder-v2.js	95 kB
dist/recorder.js	58.3 kB

_{compressed-size-action}

[benjackwhite]

Low context but tests look good so trusting you know what you're doing 😅

[neilkakkar]

Ok, figured out what the resetQueue was for: it's for any identify() that happens in the loaded callback, because that is called before decide is called, so we don't want to enqueue requests again for this.

Phew, this is very spider webby. But I added a few new explicit tests for this, to make future refactors easier.