feat(avro): PR-OUTBOX-PREREQ-PROTO-v2 — TicketMinted Tier-C strip (ADR-0002 §3b.11) #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/outbox-prereq-proto-v2-ticket-minted-pointer-based"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
TL;DR
CONDITIONAL_APPROVE candidate — strips 3 Tier-C / minor-protected fields from
TicketMinted.avscper ADR-0002 §3b.11 inim2be-mono. Pure schema edit (5 lines added, 49 lines removed). JSON validity verified. BREAKING-change against PR #3 (dade715); consumers re-codegen against v2.Summary
This PR ships only the
.avscedit referenced by the operator-locked decision in ADR-0002 §3b.11 (seeim2be-mono@145e053). The change stripssubscription_tier+parental_state(incl. nestedParentalControlStateSnapshot) +is_adminfromTicketMinted, leaving:The 3 stripped fields were flagged by Codex 2nd-reviewer (Memora #3548) as Tier-C / minor-protected PII under EDPB Guidelines 8/2020 §III + COPPA when shipped inline on Kafka — incompatible with the ADR-0014 §data-retention-and-privacy contract (
im2be-mono@82b02b2, Conditional Accept pending this PR's merge).Wave A is now uniformly pointer-based across all 3 services (identity / social-login / diary). Consumers needing the stripped fields fetch CURRENT state from identity-service via existing access-RPC semantics; audit-grade history routes to ADR-0013 §4. No bespoke historical-snapshot RPC is provisioned — §3b.9 consumer audit confirmed no documented consumer needs one (Memora #3550).
Findings
This is R0 (initial open). Pre-emptive observations:
avro/identity/ticket/event/v1/ticket_minted.avsc:1-54dade715)identity.ticket.minted.v1-valuesubject's TicketMinted schema drops 3 fields. Apicurio Schema Registry will flag this as BACKWARD-incompatible — that is intended. Topic-namespace.vNbump happens in PR-OUTBOX-1 Wave A.2 when the producer wires up (not in scope for THIS PR).avro/identity/ticket/event/v1/ticket_minted.avsc:5schema_versionfield-default bumped 1→2defaultupdates from 1→2 to match the v2 semantics. Readers using OLDER schemas will receiveschema_version=2(the new default); this is forward-compatible per Avro's schema-evolution rules.grep -rn "subscription_tier|parental_state|is_admin|ParentalControlStateSnapshot" .. TheSubscriptionTierproto enum inrealtime/v1+user/v1is INDEPENDENTLY defined and unaffected.Verdict
CONDITIONAL_APPROVEcandidate. Single-file schema edit; JSON validity verified; no cross-references to stripped fields elsewhere in the protobuf submodule.Verification
Related
im2be-mono— Decision history (TicketMinted inline → pointer-based, 2026-05-27):affinity-intelligence-rework/im2be-mono@145e053/docs/decisions/0002-centrifugo-opaque-ticket.mdim2be-mono— Conditional Accept @82b02b2; flips to ACCEPTED on this PR's merge.planning/31-wave-a-outbox-playbook.md§Per-service / identity — Wave A.2 PR-OUTBOX-1 inherits this v2 schemadade715) for the TicketMinted schema. TicketExpired + TicketRevoked unchanged (they already carry only reference IDs).Footer: im2be-protobuf • PR-OUTBOX-PREREQ-PROTO-v2 • R0 (initial) • tally
1 file changed / +5 −49 lines / 3 PII fields stripped / 8 fields retained• 2026-05-27Show previous round
hib-pr-reviewer review — PR #4 (affinity-intelligence-rework/im2be-protobuf)
Round 1 — head
03ce262c1aa5, basemain, triggeropenedTL;DR: NEEDS_WORK — kept 1 unique-to-A finding after direct file + README verification confirms the schema_version doc string misclassifies a backward-compatible removal as a breaking change, creating a policy-signal contradiction.
Summary
Arbitration — Round 1
Actions taken:
Verification of A's finding:
/var/lib/pr-reviewer/repos/affinity-intelligence-rework/im2be-protobuf/946/avro/identity/ticket/event/v1/ticket_minted.avsc→ line 21 contains exactly:"Bumped to 2 on the v1→v2 strip per ADR-0002 §3b.11. Future BACKWARD-COMPATIBLE schema additions bump this counter further. Breaking changes (like this v1→v2) instead bump the topic-namespace .vN suffix (identity.ticket.minted.v1 → .v2)."avro/README.md→ line 34: "schema_version: explicit int field… bumped on backward-compatible additions"; line 43: "✅ Removing a field that had a default" (listed under backward-compatible operations).defaultvalues ("UNSPECIFIED",null,false), satisfying the README's ✅ criterion.avro/identity/ticket/event/v1/ticket_minted.avscand the Kafka subject staysidentity.ticket.minted.v1-value; no.vNbump was made.Conclusion: The doc string at line 21 explicitly calls this change a "breaking change" and uses it as a positive example of when a
.vNtopic bump must happen — yet no such bump was performed, and the README directly classifies field-removal-with-default as backward-compatible. The contradiction is verbatim-confirmed in the file. Finding kept at major severity.Blast Radius
The diff touches a single Avro schema file within one event-package directory (
avro/identity/ticket/event/v1/). The Kafka subject (identity.ticket.minted.v1-value) and the schema's filesystem path are unchanged, so the blast radius is limited to consumers of this topic and the outbox publisher that registers the schema at startup. The misleading doc string is the primary risk vector; the structural field removals are confined to this one record.BLAST_SCORE: 3/10
Risk Indicators
subscription_tier,parental_state,is_adminCI status (head
03ce262c1aa5)Overall: ✗ failure
3 checks: 3 pending
Related PRs
Findings (1)
[MAJOR]
schema_versiondoc misclassifies a backward-compatible removal as a "breaking change" requiring a.vNtopic bump — but no such bump was madeavro/identity/ticket/event/v1/ticket_minted.avsc:21
Verified at HEAD. Line 21 reads:
This creates two direct contradictions with
avro/README.md:✅ Removing a field that had a defaultas a backward-compatible operation. All three stripped fields carried defaults ("default": "UNSPECIFIED","default": null,"default": false). This PR therefore executed a backward-compatible removal, not a breaking change.schema_versionas a counter "bumped on backward-compatible additions". The doc string now re-purposes it as evidence of a breaking change, contradicting the field's own definition.The schema correctly stays at
avro/identity/ticket/event/v1/with subjectidentity.ticket.minted.v1-value— consistent with a backward-compatible evolution — yet the doc string says the rule for such a situation is to produce a new.vNtopic suffix. Any automated policy enforcer that reads doc strings for compliance signals (e.g. "breaking change … must bump .vN") will flag this indefinitely.Proposed fix — replace the
schema_versiondoc with an accurate classification:Verdict
NEEDS_WORK
hib-pr-reviewer • round 1 • 1 finding (1M) • 2026-05-27T14:53:59.509Z → 2026-05-27T14:55:04.337Z • posted-as: pr-reviewer-bot
Show previous round
hib-pr-reviewer review — PR #4 (affinity-intelligence-rework/im2be-protobuf)
Round 2 — head
be7ce1e6f8b9, basemain, triggersynchronizeTL;DR: CONDITIONAL_APPROVE — 1 agreed finding kept (both reviewers independently cited the same file:line with materially identical bodies, verified at HEAD); no blocking issues.
Summary
Arbitration — round 2
Both reviewers A and B independently flagged the exact same defect at the same file and line: the
schema_versiondoc on line 21 ends with "Future BACKWARD-COMPATIBLE additions increment this counter further" — but this PR itself bumpedschema_versionfor a backward-compatible removal, not an addition. I verified the file at HEAD and confirmed the contested text is present verbatim on line 21. The finding is real and both reviewers agree on it.Disposition: 1 agreed finding → kept as-is at its original
minorseverity. B's suggested replacement text ("additions of a new defaulted field, removals of a defaulted field, or union arm additions") is slightly more exhaustive than A's, but both proposed fixes are materially equivalent; I surface B's more concrete wording in the body as a preference note. A also notes thatavro/README.md:34carries the same stale phrasing — I checked briefly but that file is unchanged by this PR and falls outside the diff scope, so it is flagged as a non-blocking note rather than a separate finding.Blast Radius
The diff touches a single Avro schema file. The change removes three PII fields from an event schema already in production, which affects downstream consumers who read from
identity.ticket.minted.v1-value. Because all removed fields carried Avro defaults the backward-compatibility contract is preserved; blast radius is bounded to schema-registry registration and consumer code that referenced the stripped fields by name.BLAST_SCORE: 2/10
Risk Indicators
subscription_tier,parental_state,is_adminCI status (head
be7ce1e6f8b9)Overall: ✗ failure
3 checks: 3 pending
Findings (1)
[MINOR]
schema_versiondoc forward-looking clause restricts future bumps to "additions" — inconsistent with the removal-bump this PR establishesavro/identity/ticket/event/v1/ticket_minted.avsc:21
Line 21 (
"doc"ofschema_version) ends with:Verified at HEAD: the word "additions" is present verbatim. This PR bumped
schema_versionfor a backward-compatible field removal, not an addition. A future maintainer who removes another defaulted field will read this guidance as saying removals do not warrant a counter increment — the opposite of the precedent being set here, and an audit-trail gap.Suggested replacement for the forward-looking sentence:
This matches the full ✅ rule set in
avro/README.md §Backward-compatibility rulesand is consistent with this PR's own action.Non-blocking note:
avro/README.md:34reportedly carries identical stale phrasing ("bumped on backward-compatible additions") and was not updated by this PR. That file is out of diff scope for this PR; a follow-on ticket is recommended.Verdict
CONDITIONAL_APPROVE
hib-pr-reviewer • round 2 • 1 finding (1m) • 2026-05-27T15:01:06.189Z → 2026-05-27T15:01:32.674Z • posted-as: pr-reviewer-bot
Show previous round
hib-pr-reviewer review — PR #4 (affinity-intelligence-rework/im2be-protobuf)
Round 3 — head
675ee339d88b, basemain, triggersynchronizeTL;DR: CONDITIONAL_APPROVE — kept 1 unique-to-A minor finding (verified at line 5); Reviewer B produced an empty findings array (parse-fallback); no blocking issues remain.
Summary
Arbitration — Round 3
Input: Reviewer A: 1 minor finding. Reviewer B: 0 findings (parse-fallback;
findingsarray is[]; prose summary is best-effort salvage only and carries no authority under rule 2).Agreed findings: None — B's
findingsis empty.Unique-to-A verification: Read
/var/lib/pr-reviewer/repos/affinity-intelligence-rework/im2be-protobuf/950/avro/identity/ticket/event/v1/ticket_minted.avscin full.Line 5 confirmed. The record-level
docfield contains two distinct paragraphs separated by\n\n:"…Subject convention: identity.ticket.minted.v1-value. Sticky-partitioned by user_id…"— subject is stated here."v2 schema (2026-05-27, supersedes v1 which inlined …)"— announces schema bump here, no explicit back-reference to the subject staying.v1-value.Reviewer A's concern is confirmed: a reader skimming the
docfield — or tooling that renders only the first sentence of the record description — will see "v2 schema … supersedes v1" without an explicit note that the Kafka subject intentionally remainsidentity.ticket.minted.v1-value(in-place evolution, not a topic rename). The subject mention and the v2 announcement live in separate paragraphs with no bridging sentence. Theschema_versionfield doc at line 21 carries the full explanation, but record-level and field-level docs are surfaced independently by most Schema Registry UIs and doc generators.Finding is grounded and kept at minor severity. Reviewer B's truncated prose hinted at a README concern (avro/README.md line 34) but no structured finding was produced; under rule 4 that claim is dropped without further action.
Outcome: 1 unique-to-A finding kept; 0 dropped.
Blast Radius
Only one file is touched (
avro/identity/ticket/event/v1/ticket_minted.avsc). The change removes three fields from an existing Avro subject and bumps the schema_version default; blast radius is limited to consumers of theidentity.ticket.minted.v1-valueKafka topic. All removed fields carried Avro defaults, so schema compatibility is backward-compatible and existing consumers are not broken.BLAST_SCORE: 3/10
CI status (head
675ee339d88b)Overall: ✗ failure
3 checks: 3 pending
Findings (1)
[MINOR] Record-level doc announces 'v2 schema' without co-locating the 'subject stays .v1-value' clarification
avro/identity/ticket/event/v1/ticket_minted.avsc:5
The record
docat line 5 is split across two paragraphs. Para 1 states the subject convention (identity.ticket.minted.v1-value); Para 2, separated by\n\n, announcesv2 schema (2026-05-27, supersedes v1 …)with no bridging sentence explaining that the schema bump does NOT imply a new Kafka topic. The full explanation lives in theschema_versionfield doc at line 21, but record-level and field-level docs are rendered independently by Schema Registry UIs, generated API docs, and ADR reference renderers — a tooling consumer that surfaces only the record description will see the version jump without its context.Fix: append to the v2 announcement sentence:
(schema_version bumped to 2; Kafka subject intentionally remains identity.ticket.minted.v1-value — in-place evolution, see schema_version field doc for the backward-compat rationale). One sentence bridges the two paragraphs without duplicating the full deliberation.Verdict
CONDITIONAL_APPROVE
hib-pr-reviewer • round 3 • 1 finding (1m) • 2026-05-27T15:06:32.629Z → 2026-05-27T15:07:38.698Z • posted-as: pr-reviewer-bot
hib-pr-reviewer review — PR #4 (affinity-intelligence-rework/im2be-protobuf)
Round 4 — head
1667a2e60e10, basemain, triggersynchronizeTL;DR: NO_NEW_FINDINGS — No new findings this round.
Summary
[quorum-converged] A=0 = B=0. ## Round 4 Review
Prior findings status
All three carried conditions are resolved:
avro/README.md✅ rule for removing a defaulted field and explains the in-place evolution.Kafka subject intentionally remains identity.ticket.minted.v1-value — in-place evolutionimmediately after the v2 declaration.New findings this round
Three latent issues exposed by the diff, only one of which is in scope for this PR:
avro/README.md:34§Naming-conventions still says schema_version is "bumped on backward-compatible additions" — the diff's new schema_version doc now establishes removals of defaulted fields as a valid bump trigger, making the README stale and self-contradictory for future contributors.ticket_expired.avsc:42consumedfield doc cross-referencesis_admin pattern— that field was stripped in this PR; the reference is now a dangling pointer.ticket_revoked.avsc:21andticket_expired.avsc:22carry the old schema_version boilerplate ("additions" only) that diverges from the new contract this PR establishes.CI status (head
1667a2e60e10)Overall: ✗ failure
3 checks: 3 pending
Findings
No new findings this round.
Quorum converged on empty findings (A + B both returned 0).
Verdict
NO_NEW_FINDINGS
hib-pr-reviewer • round 4 • 0 findings • 2026-05-27T15:40:19.370Z → 2026-05-27T15:42:55.583Z • posted-as: pr-reviewer-bot • [bookkeeping fallback]