fix: make integration installation atomic - #663
Merged
Conversation
Member
Author
|
|
Contributor
Prompt To Fix All With AI### Issue 1
posthog-android/src/main/java/com/posthog/android/internal/PostHogActivityLifecycleCallbackIntegration.kt:97
**Non-owner teardown clears installation**
When separate PostHog instances concurrently install this integration, the instance that loses the install CAS still clears the shared flag and unregisters its own unregistered callback during shutdown. This releases the winning instance's ownership, can trigger an invalid callback removal, and allows a later setup to register a duplicate callback; the same ownership error affects the sibling integrations using this shared guard pattern.
### Issue 2
posthog/src/main/java/com/posthog/errortracking/PostHogErrorTrackingAutoCaptureIntegration.kt:57-60
**Handler state races with teardown**
When a remote-config installation overlaps `close()`, installation marks the integration active before registering the process-wide handler. Teardown can clear the flag and restore the previous handler between those operations, after which installation registers this handler while the flag remains false, leaving exception autocapture active after shutdown.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix: make integration installation atomi..." | Re-trigger Greptile |
Contributor
posthog-android Compliance ReportDate: 2026-07-29 09:20:30 UTC ✅ All Tests Passed!46/46 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
ioannisj
approved these changes
Jul 29, 2026
marandaneto
enabled auto-merge (squash)
July 29, 2026 09:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
💡 Motivation and Context
Concurrent setup of multiple PostHog instances can race through the
@Volatileread-then-write guards used by default integrations.@Volatileguarantees visibility but not an atomic check-and-set, allowing duplicate legacy flushes, lifecycle callbacks, replay listeners, logcat threads, and other integration side effects.Closes #662.
This also fixes the same pattern in the seven other affected integrations found during the repository-wide audit. Each integration tracks whether its instance won installation, preventing a losing instance from clearing the winner's shared state during teardown. Install and uninstall are synchronized per instance so remote-config updates cannot race with teardown side effects. Cached-event integrations that lose installation also shut down their unused executor.
💚 How did you test it?
JAVA_TOOL_OPTIONS=-Dnet.bytebuddy.experimental=true make testJava./gradlew :posthog:apiCheckmake checkFormat📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Implemented with the Pi coding agent using repository inspection, shell, editing, and test tools. The audit covered every production
@VolatileBoolean and limited the change to the eightintegrationInstalledguards that perform a check-and-set. Review feedback led to owner-aware teardown and per-instance synchronization across those guards; other volatile fields remain unchanged because they are visibility-only or already lock/thread confined.