refactor: remove dry4go duplicate candidates

[marandaneto]

💡 Motivation and Context

PoC for evaluating duplicate removal surfaced by dry4go.

This refactors the repository to remove the duplicate candidates reported by dry4go while preserving existing behavior. It also makes feature-flag event assertions wait more reliably under the race-enabled CI run.

💚 How did you test it?

• go test ./...
• go test -race -count=1 -timeout=5m ./...
• dry4go . → No duplicate candidates found.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran pnpm changeset to generate a changeset file

[github-actions]

posthog-go Compliance Report

Date: 2026-06-04 15:25:31 UTC
Duration: 107378ms

⚠️ Some Tests Failed

39/45 tests passed, 6 failed

---

Capture Tests

✅ 29/29 tests passed

View Details

Test	Status	Duration
Format Validation.Event Has Required Fields	✅	611ms
Format Validation.Event Has Uuid	✅	608ms
Format Validation.Event Has Lib Properties	✅	609ms
Format Validation.Distinct Id Is String	✅	608ms
Format Validation.Token Is Present	✅	608ms
Format Validation.Custom Properties Preserved	✅	608ms
Format Validation.Event Has Timestamp	✅	608ms
Retry Behavior.Retries On 503	✅	5614ms
Retry Behavior.Does Not Retry On 400	✅	2611ms
Retry Behavior.Does Not Retry On 401	✅	2611ms
Retry Behavior.Respects Retry After Header	✅	5614ms
Retry Behavior.Implements Backoff	✅	15624ms
Retry Behavior.Retries On 500	✅	5614ms
Retry Behavior.Retries On 502	✅	5613ms
Retry Behavior.Retries On 504	✅	5614ms
Retry Behavior.Max Retries Respected	✅	15623ms
Deduplication.Generates Unique Uuids	✅	618ms
Deduplication.Preserves Uuid On Retry	✅	5613ms
Deduplication.Preserves Uuid And Timestamp On Retry	✅	10614ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	5614ms
Deduplication.No Duplicate Events In Batch	✅	612ms
Deduplication.Different Events Have Different Uuids	✅	611ms
Compression.Sends Gzip When Enabled	✅	608ms
Batch Format.Uses Proper Batch Structure	✅	608ms
Batch Format.Flush With No Events Sends Nothing	✅	605ms
Batch Format.Multiple Events Batched Together	✅	611ms
Error Handling.Does Not Retry On 403	✅	2611ms
Error Handling.Does Not Retry On 413	✅	2610ms
Error Handling.Retries On 408	✅	5613ms

Feature_Flags Tests

⚠️ 10/16 tests passed, 6 failed

View Details

Test	Status	Duration
Request Payload.Request With Person Properties Device Id	❌	9ms
Request Payload.Flags Request Uses V2 Query Param	✅	6ms
Request Payload.Flags Request Hits Flags Path Not Decide	✅	7ms
Request Payload.Flags Request Omits Authorization Header	✅	6ms
Request Payload.Token In Flags Body Matches Init	✅	6ms
Request Payload.Groups Round Trip	✅	7ms
Request Payload.Groups Default To Empty Object	✅	6ms
Request Payload.Person Properties Distinct Id Auto Populated When Caller Omits It	❌	7ms
Request Payload.Disable Geoip False Propagates As Geoip Disable False	❌	6ms
Request Payload.Disable Geoip Omitted Defaults To False	❌	7ms
Request Payload.Flag Keys To Evaluate Contains Only Requested Key	❌	7ms
Request Lifecycle.No Flags Request On Init Alone	✅	3ms
Request Lifecycle.No Flags Request On Normal Capture	✅	607ms
Request Lifecycle.Two Flag Calls Produce Two Remote Requests	✅	10ms
Request Lifecycle.Mock Response Value Is Returned To Caller	✅	6ms
Side Effect Events.Get Feature Flag Captures Feature Flag Called Event	❌	609ms

Failures

request_payload.request_with_person_properties_device_id

Field 'distinct_id' not found in /flags request body at path 'person_properties.distinct_id'. Available keys: ['$device_id']

request_payload.person_properties_distinct_id_auto_populated_when_caller_omits_it

Field 'distinct_id' not found in /flags request body at path 'person_properties.distinct_id'. Available keys: ['email']

request_payload.disable_geoip_false_propagates_as_geoip_disable_false

Expected geoip_disable=False, got True

request_payload.disable_geoip_omitted_defaults_to_false

Expected geoip_disable=False, got True

request_payload.flag_keys_to_evaluate_contains_only_requested_key

Field 'flag_keys_to_evaluate' not found in /flags request body at path 'flag_keys_to_evaluate'. Available keys: ['api_key', 'distinct_id', 'groups', 'person_properties', 'group_properties', 'geoip_disable']

side_effect_events.get_feature_flag_captures_feature_flag_called_event

Expected 1 events with name '$feature_flag_called', got 2

[greptile-apps]

Comments Outside Diff (2)

1. feature_flags_flags_test.go, line 39-50 (link)

   Silent minimum-timeout floor surprises callers

   The 5-second floor is applied to every call in feature_flags_flags_test.go that passes time.Second. The callers have no indication their timeout is overridden, so a flaky test that normally times out in 1s will now hang for 5s instead — multiplied by the 15+ call sites in that file. If the floor is needed for race-CI reliability, a comment at the definition site would prevent future confusion, and call sites could also be updated to pass the actual desired value (5*time.Second) explicitly.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: feature_flags_flags_test.go
   Line: 39-50
   
   Comment:
   **Silent minimum-timeout floor surprises callers**
   
   The 5-second floor is applied to every call in `feature_flags_flags_test.go` that passes `time.Second`. The callers have no indication their timeout is overridden, so a flaky test that normally times out in 1s will now hang for 5s instead — multiplied by the 15+ call sites in that file. If the floor is needed for race-CI reliability, a comment at the definition site would prevent future confusion, and call sites could also be updated to pass the actual desired value (`5*time.Second`) explicitly.
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

2. capture_local_eval_test.go, line 448-483 (link)

   Inconsistent server lifecycle in assertCaptureFeatureFlagFallback

   Every other new helper added in this PR (newSlowBatchServer, newBatchCounterServer, newFlagDependencyClient, newFeatureFlagsFixtureClient, newFeatureFlagsLocalClient) registers server cleanup with t.Cleanup(server.Close), ensuring the server outlives the client. Here defer server.Close() fires when the helper returns — before t.Cleanup(func() { cli.Close() }) runs — so cli.Close() drains against an already-closed server. In the current test this is harmless because BatchSize: 1 means the batch is flushed before waitForEvent returns, but using t.Cleanup(server.Close) would align with the rest of the PR and prevent confusion if the helper is extended.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: capture_local_eval_test.go
   Line: 448-483
   
   Comment:
   **Inconsistent server lifecycle in `assertCaptureFeatureFlagFallback`**
   
   Every other new helper added in this PR (`newSlowBatchServer`, `newBatchCounterServer`, `newFlagDependencyClient`, `newFeatureFlagsFixtureClient`, `newFeatureFlagsLocalClient`) registers server cleanup with `t.Cleanup(server.Close)`, ensuring the server outlives the client. Here `defer server.Close()` fires when the helper returns — before `t.Cleanup(func() { cli.Close() })` runs — so `cli.Close()` drains against an already-closed server. In the current test this is harmless because `BatchSize: 1` means the batch is flushed before `waitForEvent` returns, but using `t.Cleanup(server.Close)` would align with the rest of the PR and prevent confusion if the helper is extended.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
feature_flags_flags_test.go:39-50
**Silent minimum-timeout floor surprises callers**

The 5-second floor is applied to every call in `feature_flags_flags_test.go` that passes `time.Second`. The callers have no indication their timeout is overridden, so a flaky test that normally times out in 1s will now hang for 5s instead — multiplied by the 15+ call sites in that file. If the floor is needed for race-CI reliability, a comment at the definition site would prevent future confusion, and call sites could also be updated to pass the actual desired value (`5*time.Second`) explicitly.

### Issue 2 of 2
capture_local_eval_test.go:448-483
**Inconsistent server lifecycle in `assertCaptureFeatureFlagFallback`**

Every other new helper added in this PR (`newSlowBatchServer`, `newBatchCounterServer`, `newFlagDependencyClient`, `newFeatureFlagsFixtureClient`, `newFeatureFlagsLocalClient`) registers server cleanup with `t.Cleanup(server.Close)`, ensuring the server outlives the client. Here `defer server.Close()` fires when the helper returns — before `t.Cleanup(func() { cli.Close() })` runs — so `cli.Close()` drains against an already-closed server. In the current test this is harmless because `BatchSize: 1` means the batch is flushed before `waitForEvent` returns, but using `t.Cleanup(server.Close)` would align with the rest of the PR and prevent confusion if the helper is extended.

_{Reviews (1): Last reviewed commit: "test: make feature flag event assertions..." | Re-trigger Greptile}