Add support for enqueueing daily and unique pixels#7639
Conversation
lmac012
force-pushed
the
feature/lukasz/enqueue-daily-and-unique-pixels
branch
from
da5c874 to
9985b3a
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| pixel: PixelName, | ||
| parameters: Map<String, String>, | ||
| encodedParameters: Map<String, String>, | ||
| type: PixelType, |
There was a problem hiding this comment.
Type parameter not passed in enqueueFire fake implementation
Low Severity
The FakePixel test implementation adds the new type parameter to both enqueueFire method signatures but doesn't actually use it. At line 62, the call to the overloaded enqueueFire doesn't pass the type parameter. At line 76, PixelType.Count is hardcoded instead of using the type parameter. This differs from how the fire() methods in the same file correctly pass through the type parameter and is inconsistent with the production RxBasedPixel implementation.
Additional Locations (1)
landomen
left a comment
landomen
left a comment
There was a problem hiding this comment.
Looks good to me. Thanks for aligning the APIs 🏅
| encodedQueryParams = encodedParameters, | ||
| ) | ||
| pendingPixelDao.insert(pixelEntity) | ||
| storePixelFired(pixelName, type) |
There was a problem hiding this comment.
Is my thinking here correct: calling this ensures only one Daily/Unique pixel is fired even if another part of the app calls pixel.fire() on the same pixel?
There was a problem hiding this comment.
Correct. fire() and enqueueFire() share the same underlying storage to keep track of which unique or daily pixels have already been fired. So, for example, if the code previously used fire() to send a unique pixel and is later updated to use enqueueFire(), that pixel won’t be fired a second time.
2 participants
Task/Issue URL: https://app.asana.com/1/137249556945/project/488551667048375/task/1213068706396582?focus=true
Description
This PR adds PixelType param to enqueueFire() method in the Pixel interface, aligning functionality between fire() and enqueueFire() methods.
Steps to test this PR
The new API is not in use yet, so this PR is QA-optional.
No UI changes
Note
Medium Risk
Medium risk because it changes the core analytics enqueueing contract and adds new suppression logic for daily/unique pixels, which could alter what gets persisted and sent if misapplied.
Overview
Aligns
Pixel.enqueueFirewithfireby adding aPixelTypeparameter (defaulting toCount) so enqueued pixels can be treated as count, daily, or unique events.Updates
PixelSender.enqueuePixelto acceptPixelTypeand returnSingle<EnqueuePixelResult>(PIXEL_ENQUEUED/PIXEL_IGNORED), and changesRxPixelSenderto apply the same daily/unique suppression + fired-state tracking when enqueueing (not just when sending).Adjusts
RxBasedPixellogging to reflect enqueue outcomes, and updates stubs/fakes and unit tests across modules to pass the newtypeargument and assert the new behavior.Written by Cursor Bugbot for commit 9985b3a. This will update automatically on new commits. Configure here.