Skip to content

Fix flaky pgsql malformed-packet TAP assertion for rapid Sync frames #6090

Description

@renecannao

Summary

CI-legacy-g4 can fail even though ProxySQL handles the tested PostgreSQL traffic normally.

The failed check on PR #6080 was run 31881171728. It completed 37 of 38 runnable TAP tests; the only failure was pgsql-test_malformed_packet-t:

not ok 83 - Rapid fire sync packets: Phase 2 malformed packet handled
           (closed=0, timeout=0, error=0, first=0x5A)

0x5A is PostgreSQL ReadyForQuery.

Root cause

The test's “Rapid fire sync packets” case emits 100 complete Sync frames:

{'S', 0x00, 0x00, 0x00, 0x04}

It then treats only an ErrorResponse, a disconnect, or a timeout as success. A normal ReadyForQuery response is ignored, so a responsive ProxySQL instance fails the TAP assertion; an unresponsive/timed-out one passes.

This is timing-dependent. The immediately preceding PR #6080 workflow (run 31873149477) ran the same TAP as test 129/428 and passed all 38 runnable tests. PR #6080 does not change pgsql-test_malformed_packet-t or PgSQL production code. Its newly-added EOF workload runs after the root TAP group containing this failure.

Expected resolution

Keep the rapid-Sync stability coverage, but classify ReadyForQuery as a valid graceful response, alongside ErrorResponse, connection close, and timeout. Rename/diagnose the case accurately so it no longer describes valid Sync traffic as malformed.

Scope

This is a TAP-test correctness fix. No ProxySQL production behavior is implicated by the failure.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions