fix: retain events after network flush failures

[marandaneto]

💡 Motivation and Context

QueueConsumer::flush() removed a batch from the in-memory queue before sending it. When the send failed due to a transient network or timeout failure, those events were lost even though retrying later could succeed.

This change keeps batches queued for retryable transport failures while still dropping non-retryable failures so a permanently bad batch does not block later events.

💚 How did you test it?

• vendor/bin/phpcs lib/QueueConsumer.php lib/Consumer/LibCurl.php lib/Consumer/Socket.php lib/Consumer/ForkCurl.php lib/HttpClient.php test/QueueConsumerTest.php test/QueueConsumerTestConsumer.php test/MockedHttpClient.php
• vendor/bin/phpunit --no-coverage test/QueueConsumerTest.php
• composer api:check
• vendor/bin/phpunit --no-coverage

📝 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

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

The implementation was authored with pi. The chosen approach introduces internal flush failure classifications so queue consumers can keep events only for retryable network/timeout failures and continue dropping non-retryable batches such as oversized payloads, compression failures, retry exhaustion, and non-200 responses.

For PHP specifically, the batch HTTP client keeps its narrower retry policy instead of retrying every non-2xx/3xx response. PHP sends synchronously in the hosting app request path, so broad retries could slow down the host application; 413 payload-too-large is also not retried. Review feedback was addressed by simplifying the retry branch and parameterizing repeated LibCurl queue behavior tests.

[greptile-apps]

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
lib/HttpClient.php:162-171
Three consecutive `elseif`/`else` branches all resolve to a single unconditional `break`, repeating the same statement three times with no differentiation in outcome. The `$responseCode >= 400` and `$responseCode == 0` cases can be folded into a single `else` clause — the only branch that actually diverges from the default here is the 5xx/429 retry.

```suggestion
                } else {
                    // Do not retry non-5xx/non-429 responses (e.g. 4xx, 413 Payload Too Large,
                    // or responseCode 0 for network errors). PHP sends synchronously in the hosting
                    // app's request path, so broad retries would slow down the host application.
                    break;
                }
```

### Issue 2 of 2
test/QueueConsumerTest.php:73-117
**Tests should be parameterised**

`testLibCurlNetworkFailureKeepsBatchQueued`, `testLibCurlHttpFailureDropsBatch`, and `testLibCurlPayloadTooLargeDropsBatch` share identical structure — they differ only in `batchEndpointResponse`, `batchEndpointResponseCode`, `batchEndpointCurlErrno`, and whether the queue retains the event. Per the team's standard these should be a single `#[DataProvider]` test (or `@dataProvider` for older PHPUnit), keeping each scenario as a data row and consolidating the assertion logic once.

_{Reviews (1): Last reviewed commit: "fix: retain events after network flush f..." | Re-trigger Greptile}

[greptile-apps]

_{Reviews (2): Last reviewed commit: "address pr review feedback" | Re-trigger Greptile}

[ioannisj]

LG, tried to follow the logic as close as possible and seems correct