feat: run background queue tasks #78
Conversation
levibostian
force-pushed
the
background-q-runner
branch
from
91352d0 to
197541e
Compare
Sources/Tracking/Background Queue/Task Data/TrackEventQueueTaskData.swift
Show resolved
Hide resolved
There was a problem hiding this comment.
a couple things to note:
- Retrying of tasks needs to be nuanced. 50x errors should retry, 40x shouldn't since they have in some way been found unprocessable. Once we get to global error handling this can probably be handed off to the customer for input as well
- How much do we trust device timestamps? we're setting it to the timestamp at the time the request is queued. This could be a problem if the clock time is off by enough margin to have events treated as non-triggering due to device issues. A bit of an extreme case, but might be worth having a convo about whether we're comfortable using device time always / having a look at how other platforms do the same
| init( | ||
| siteId: SiteId, | ||
| storage: QueueStorage, | ||
| runRequest: QueueRunRequest, |
There was a problem hiding this comment.
I'll defer to @ami-aman and possibly @Shahroz16 on the readability side, as I'm still quite new to Swift and am definitely not the target audience here!
| self.logger.verbose("background queue task \(nextTaskStorageId) success") | ||
|
|
||
| _ = self.storage.delete(storageId: nextTaskToRunInventoryItem.taskPersistedId) | ||
| case .failure(let error): |
There was a problem hiding this comment.
we should be differentiating between issues in CIO (50x) and issues from the customer (40x)
| runResults: newRunResults) | ||
| } | ||
|
|
||
| return goToNextTask() |
There was a problem hiding this comment.
a bit of an interesting questions as to what we should do if a request fails, I think it's probably fine to just continue in the queue due to how we handle customer creation, but worth having a think about the use case where there are two items in the queue:
request1 -> initial identify
request2 -> add device
request3 -> send event
if request1 fails and defers to later then the profile could in theory be empty and just contain a device until the queue is run again. Likely a small window, but it does raise the question as to whether the initial identify should be given a blocking behaviour 🤔 so that until it gets a non 50x response we don't continue. Or possibly any 50x stops the queue?
2nd milestone of the background queue: running tasks.