fix: satisfy SDK compliance harness 0.8.0#455
Conversation
marandaneto
changed the title
|
Reviews (1): Last reviewed commit: "chore: add SDK compliance harness 0.8.0" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
posthog-flutter Compliance ReportDate: 2026-06-29 14:48:55 UTC ✅ All Tests Passed!45/45 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 16/16 tests passed View Details
|
|
Reviews (2): Last reviewed commit: "fix: keep flags api key field" | Re-trigger Greptile |
| Future<void> resetAdapterState() async { | ||
| _flushTimer?.cancel(); | ||
| _flushTimer = null; | ||
| _apiKey = null; | ||
| _host = null; | ||
| _nextDistinctId = null; | ||
| _nextTimestamp = null; | ||
| lastCapturedUuid = null; | ||
| state = _AdapterState(); | ||
| } |
There was a problem hiding this comment.
resetAdapterState leaves in-flight flush running against the new state
_activeFlush is never cleared here and the timer is only cancelled — any ongoing flush (triggered by the timer or a previous capture) keeps running. It holds a reference to this, so after state = _AdapterState() is executed it writes to the freshly created state object: state.totalEventsSent += batch.length runs against the new clean state and corrupts it. Concurrently, flush() guards on _activeFlush != null and returns the stale future, so the first explicit /flush call from the harness after /reset does nothing — it just awaits the old operation. A compliance scenario of "reset → init → capture → flush → check state" will see non-zero total_events_sent before any event was intentionally sent in the new session.
| final sentUuids = batch.map((event) => event['uuid']).toSet(); | ||
| state.queue.removeWhere((event) => sentUuids.contains(event['uuid'])); | ||
| state.pendingEvents = state.queue.length; |
There was a problem hiding this comment.
removeWhere runs unconditionally regardless of success. When all retries are exhausted and success is false, every event in the batch is removed from the queue and pending_events drops to 0, yet total_events_sent is not updated. Any compliance scenario that checks pending_events after a permanent send failure will see 0 instead of the number of events that could not be delivered.
2 participants
Problem
The SDK compliance workflow and local harness need to use SDK test harness release 0.8.0, with reusable GitHub workflow calls pinned to the release commit SHA instead of a mutable tag/branch. Running the updated harness exposed SDK/adapter compliance gaps in this repository.
Changes
Tests