Skip to content

ADR 001: Adopt marker-interface exception hierarchy#36

Merged
turegjorup merged 3 commits into
developfrom
docs/adr-exception-contract-migration
May 11, 2026
Merged

ADR 001: Adopt marker-interface exception hierarchy#36
turegjorup merged 3 commits into
developfrom
docs/adr-exception-contract-migration

Conversation

@turegjorup
Copy link
Copy Markdown
Contributor

Summary

Records the architectural decision to migrate the bundle and its upstream itk-dev/openid-connect library to a marker-interface exception contract, as described in CLAUDE.md's "Exceptions" section.

Status: Draft — awaits team review.

What's in this PR

Two new files under docs/adr/:

  • 001-marker-interface-exception-hierarchy.md — the ADR itself: context, drivers, three options considered, the decision and rationale, consequences, and the four-PR migration sequence.
  • README.md — index for future ADRs.

No code changes. This PR is documentation only.

Why now

PR #33's review (jekuaitk) surfaced that the bundle's exception handling didn't match the design intent in CLAUDE.md. Mapping the gap revealed it's deeper than a one-PR fix — neither package has a marker interface, no concrete extends an SPL type, and the bundle and library exception hierarchies have no inheritance link. The ADR captures the decision to fix this properly via coordinated 5.0 majors, rather than continue making local fixes that don't address the underlying contract.

Migration sequence (decided in the ADR)

  • PR 0$previous-chain bug fixes, 4.x patch. In flight as PR #35.
  • PR 1 — Library 5.0 contract migration (separate repo: itk-dev/openid-connect).
  • PR 2 — Bundle 5.0 contract migration (this repo). Depends on PR 1 tagged.
  • PR 3 — Custom PHPStan rules locking the contract. Bundled inside PR 2.

Review focus

  • Is Option 1 (marker interface + SPL re-parenting + coordinated 5.0 majors) the right call vs. Option 2 (marker only, additive) or Option 3 (rewrite CLAUDE.md to match current reality)?
  • Is the controller HTTP-exception carve-out (Symfony HttpException subclasses in src/Controller/) acceptable as a documented exception to wrap-at-boundary?
  • Is the SPL-parent mapping for the concrete exception classes sensible? (Full table in the ADR's "Decision" section.)
  • Is the four-PR sequencing the right granularity, or should any be combined / split?

Approval moves status to Accepted

Once approved, status flips from "Draft" to "Accepted" and implementation can start on PR 1 (upstream library).

🤖 Generated with Claude Code

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented May 11, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (c65ff56) to head (bada46d).
⚠️ Report is 4 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##             develop       #36   +/-   ##
===========================================
  Coverage     100.00%   100.00%           
  Complexity        60        60           
===========================================
  Files              9         9           
  Lines            278       278           
===========================================
  Hits             278       278           
Flag Coverage Δ
unittests 100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Records the decision to migrate the bundle (and upstream library) to a marker-interface exception contract: cross-package marker interfaces, concretes extending SPL types, wrap-at-boundary discipline with `$previous` chained, and the controller HTTP-exception exit treated as a documented carve-out. Migration via coordinated 5.0 majors across `itk-dev/openid-connect` and this bundle, sequenced as four PRs. PR 0 (cause-chain bug fixes) already in flight as PR #35.

The ADR is self-contained: context, drivers, three options considered, decision, consequences, and references (PSR-18, Symfony's component markers and Psr18Client, Bloch's wrap-at-boundary principle).

Status: Draft — awaits team review.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@turegjorup turegjorup force-pushed the docs/adr-exception-contract-migration branch from 4ccd0dd to f2764ad Compare May 11, 2026 10:52
@turegjorup turegjorup self-assigned this May 11, 2026
@turegjorup turegjorup requested a review from jekuaitk May 11, 2026 10:58
Copy link
Copy Markdown
Collaborator

@jekuaitk jekuaitk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

turegjorup and others added 2 commits May 11, 2026 13:35
Add a short framing paragraph at the top of "Context" stating that the
marker-interface principles the ADR proposes were the intended design
all along; the implementation has drifted from intent on specific points
and this migration closes those gaps.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@turegjorup turegjorup merged commit 1faf7d8 into develop May 11, 2026
14 of 15 checks passed
@turegjorup turegjorup deleted the docs/adr-exception-contract-migration branch May 11, 2026 11:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants