Merged open-source contribution · Recruiters and engineering clients
Elastic — Proofpoint WebSocket timeout correction
Corrected the optional keep-alive default and independently verified Fleet upgrade behaviour across Audit, Mail and Message. Merged upstream and released in package 1.11.1.
Contribution by Ayobami Haastrup · Merged
The problem
Proofpoint On Demand connections could repeatedly time out when optional Keep Alive was enabled. The previous 30-second ping interval matched the fixed 30-second read deadline, allowing the connection to expire before the first keep-alive exchange completed.
My contribution
- Changed the default keep-alive interval from 30 seconds to 10 seconds in the Audit, Mail and Message data streams; Keep Alive remains opt-in.
- Documented the requirement for an interval below 30 seconds and the timeout/reconnect symptoms.
- Explained that existing policies retain saved intervals during upgrades: adjust values of 30 seconds or more manually and preserve valid custom intervals. Shared Beats engine changes remain separate.
Maintainer review
Elastic maintainer efd6 requested confirmation of package-upgrade behaviour before approval. I supplied an isolated Fleet API upgrade matrix covering saved and compiled policies.
My Fleet upgrade verification
I ran Fleet API upgrades on 3 November 2026, reporting results on 5 November, in an isolated Kibana/Fleet 9.4.1 stack with source-built 1.11.0 and 1.11.1 packages and Keep Alive enabled.
All three existing-policy upgrades succeeded, kept their policy IDs and advanced revisions from 1 to 2. The saved and compiled intervals below were verified across Audit, Mail and Message.
The tested candidate and the rebuilt reviewed head had byte-identical runtime manifests and templates; only the generated README differed. These were source-built packages, not official registry ZIPs.
| Policy case | Saved after upgrade/creation | Compiled policy |
|---|---|---|
| Existing policy with old default (interval omitted) | 30s | 30s |
| Existing policy with explicit longer interval | 120s | 120s |
| Existing policy with valid custom interval | 15s | 15s |
| Fresh 1.11.1 policy (interval omitted) | 10s | 10s |
Elastic validation and release
Elastic Buildkite #52789 passed for the reviewed PR head f026c037edd3428d7abc00c3c89c018817339583, reported on 4 November 2026. Elastic merged the contribution on 5 November 2026 at 21:49 UTC.
Elastic announced proofpoint_on_demand 1.11.1 on 5 November 2026. The reviewed source, upstream merge and package release are separate evidence events.
- Reviewed contribution head
- f026c037edd3428d7abc00c3c89c018817339583
- Upstream merge commit
- 915d8636de72ba1e9c5f5689ace8e12ed62b55d7
Evidence, status and limits
My independent tests cover Fleet API upgrade persistence and policy compilation. They do not establish a UI click-through, enrolled-agent execution, live Proofpoint ingestion or measured customer/performance improvements. Elastic operated the upstream CI, merge and package release.
- Original timeout report ↗
- Merged upstream PR #22170 ↗
- Maintainer's upgrade-behaviour question ↗
- My independent Fleet upgrade evidence ↗
- Elastic Buildkite #52789 ↗
- Buildkite success tied to reviewed head ↗
- Upstream merge commit ↗
- Published proofpoint_on_demand 1.11.1 ↗
- Elastic's package release confirmation ↗
Lessons and trade-offs
- A safer default does not migrate existing saved configuration; upgrade behaviour needs its own evidence and user guidance.
- Keep contributor-run verification, revision-matched upstream CI and the published release distinct so each claim can be checked.