Add configurable compatibility allowances to thrift audit

[zsy056]

Summary

• add --audit-allow-optional-field-removal so explicit optional fields can be removed when intentionally enabled
• add --audit-allow-required-field-to-default so required fields can move to default requiredness when intentionally enabled
• keep default-field removal, required-field removal, default-to-required, and required-to-optional changes rejected
• move configurable audit coverage into standalone .thrift fixtures
• register the audit suite with both Automake and CMake, and exercise it in GitHub Actions

Compatibility validation

Generated separate C++ bindings for required and default requiredness and tested both directions with the binary protocol:

• required writer -> default-requiredness reader: value 8675309 recovered
• default-requiredness writer -> required reader: value 8675309 recovered
• both serialized payloads were identical (8 bytes)

This confirms that removing explicit required while retaining default requiredness is wire-compatible for this transition.

Regression proof

In a disposable WSL2 checkout, I temporarily weakened the optional-removal guard so the option also allowed removal of a default-requiredness field. The registered CMake ThriftAuditTest failed on the intended negative case:

TEST FAILURE: default field removal remains rejected by optional removal option: expected exit code 2, got 0

After restoring the committed implementation, the same test passed.

Validation

• CMake build and full ctest: 18/18 passed
• rebased-head CMake ThriftAuditTest: passed
• Autotools top-level make check: passed, including test/audit
• perl -c test/audit/thrift_audit_test.pl: passed
• git diff --check: passed

Checklist

• Apache Jira ticket (not created for this contribution)
• Single commit
• No default audit behavior changed; compatibility allowances require explicit options
• Test coverage added with standalone Thrift files

AI assistance

Generated-by: OpenAI Codex (GPT-5)

[Jens-G]

required fields can move to default requiredness when intentionally enabled

But you are aware that this breaks your contract? IOW that is what audit is designed to check.

[zsy056]

required fields can move to default requiredness when intentionally enabled

But you are aware that this breaks your contract? IOW that is what audit is designed to check.

Hi Jens

I was using thrift as the internal RPC implementation of a micro-service, for this scenario, the contract is the client API of our micro-service, not the thrift definition itself.

I found audit to be externally helpful to prevent issues on wire protocol incompatibility, it is used as part of a check-in gate. However, over the years, things have changed enough that we have to remove some optional and slowly deprecate some required fields. The current audit mode doesn’t provide the flexibility and we also definitely don’t want to drop audit entirely in the check-in gate.

So I suppose if these relaxations are behind some command line option and is default to off, it should be safe for all existing users while still provide flexibility?

Thanks