Org Web Adapter

hungryroot/contract-testing/colin-vs-henry-doc.org

ID
8ca107d6-7ace-4dc0-a026-e29ff7c3f87c

Contract Testing: Colin's Proposal vs Henry's Sodapop RFC

Sources

- [[https://hungryroot.atlassian.net/wiki/spaces/BA/pages/1535868929/Backend+Project+Proposal+Contract+Testing+with+Schemathesis+and+Pact][BE: Contract Testing with Schemathesis and Pact]] (Colin Powell)

- [[https://hungryroot.atlassian.net/wiki/spaces/WD/pages/1584168961/RFC+Client-Safe+Sodapop+UI+Attachments+and+Suggested+Action+Contracts][RFC: Client-Safe Sodapop UI Attachments and Suggested Action Contracts]] (Henry Ng)

Where They Align

Both propose Pact for consumer-driven contract testing. Same model:

- Consumers: web, iOS, Android

- Provider: server

- Goal: block incompatible deploys

Both enforce explicit contract versioning (=action.add.v1=, =action.add.v2=) and

deprecation windows. Philosophically identical.

Where They Differ

| Dimension | Colin (BE) | Henry (Sodapop RFC) |

|------------------------+------------------------------------------+--------------------------------------------------|

| Layer | REST API schema (OpenAPI/DRF) | Sodapop AI response UI contracts |

| Problem | Schema drift: spec ≠ implementation | Capability mismatch: server emits UI clients can't render |

| Phase 1 | Schemathesis (OpenAPI validation) | Capability registry + server-owned profiles |

| Pact path | Pact Broker (PactFlow) from Phase 2 | Lightweight path (shared fixtures + CI) first, broker later |

| Novel concept | None beyond standard Pact | Server-side capability profiles by client identity |

| Conversation history | Not addressed | Full cross-platform replay safety model |

| Owners defined? | Placeholder [Assign Owner] | Henry authored; resolution location open question |

Key Tensions

Two Pact setups, one broker question

Colin's doc plans PactFlow from Phase 2. Sodapop RFC defers broker until

"fixtures become painful." If web ships the lightweight path first, we could

end up with divergent contract validation infrastructure before Phase 2 lands.

Scope gap

Colin's doc covers the Django REST API. Sodapop RFC covers Sodapop AI

responses. Neither covers the other's domain — but both need Pact, so the

broker ownership and CI integration need to be shared infrastructure, not two

separate things.

Capability registry is unowned

Sodapop RFC leaves open: "should resolution live in Hungryroot API layer or

Sodapop?" — that's a backend decision that directly affects Phase 2 scope.

Practical Synthesis

Colin's Phase 1 (Schemathesis) is orthogonal to the Sodapop RFC — no

conflict, different layer entirely. Start it independently.

Colin's Phase 2 (Pact Broker) *is* the Sodapop RFC's "Contract Testing With

Pact" section. Henry's doc even says as much. The smart move: coordinate on a

single shared Pact Broker before either team sets one up solo. Colin's doc has

the infra plan; Henry's doc has the Sodapop-specific contracts. They need each

other.

Recommend getting Henry into the Phase 2 kickoff (already scheduled June 3).

The capability registry ownership question is a blocker for both.