Files
document-haness/docs/clean-architecture-backend-template/final/evidence/raw/analysis-finding-a04-f004.txt
T
DongHyeonkaandClaude Opus 5 b2963105a8 docs(keycloak-session-store): import the session-storage lab as a new project
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.

Follows the import procedure in README.md.

  source/     the originating repository verbatim — 78 documents, 28 SVGs,
              8 manifests, plus .source-revision recording the commit
  final/      the SSOT
    document.md   729 lines written from the 29 experiment documents, not
                  concatenated: what was predicted, what was measured, and
                  where the measurement itself was wrong
    evidence/raw    125 outputs, flattened to <experiment>__<file> because
                    the originals collided (01-baseline.txt appeared three
                    times) and the audit only globs the top level
    evidence/meta   one per raw file; command and exitCode are null and the
                    README says why rather than inventing them
    evidence/browser  22 captures
    assets/       three diagrams through techviz
    .techviz/     their VizSpecs

A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.

Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.

verify-pipeline.py passes. audit-records.py reports no issues.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 22:51:59 +09:00

90 lines
6.2 KiB
Plaintext

# 이 데코레이터가 자기에게 매긴 계약
FailOpenNotificationProvider.java:7 /**
FailOpenNotificationProvider.java:8 * Fail-open decorator: a provider failure is logged (no payload/PII) and swallowed so a
FailOpenNotificationProvider.java:9 * notification — a side-effect — never fails the core use case. Applied centrally by
FailOpenNotificationProvider.java:10 * NotificationConfig.
FailOpenNotificationProvider.java:11 */
# 실패 경로 : catch 안에서 실패 로그를 부른다
FailOpenNotificationProvider.java:35 @Override
FailOpenNotificationProvider.java:36 public void send(Notification notification) {
FailOpenNotificationProvider.java:37 try {
FailOpenNotificationProvider.java:38 delegate.send(notification);
FailOpenNotificationProvider.java:39 dependencyLogger.logSuccess(delegate.providerId(), DEPENDENCY_TYPE, "send");
FailOpenNotificationProvider.java:40 } catch (Exception ex) {
FailOpenNotificationProvider.java:41 // fail-open: observe (no payload/PII), do not fail the core use case.
FailOpenNotificationProvider.java:42 dependencyLogger.logFailure(delegate.providerId(), DEPENDENCY_TYPE, "send", ex);
FailOpenNotificationProvider.java:43 }
FailOpenNotificationProvider.java:44 }
FailOpenNotificationProvider.java:45 }
# 메시징 쪽의 같은 자리 : catch 안도 observeQuietly 를 거친다
OutboundMessagePublisher.java:26 @Override
OutboundMessagePublisher.java:27 public void publish(OutboundMessage message) {
OutboundMessagePublisher.java:28 // The send and the observation are separate steps because they used to share a try block: a
OutboundMessagePublisher.java:29 // logger that threw after a successful send was caught by the same catch and reported as a
OutboundMessagePublisher.java:30 // publish failure. The broker had accepted the message; the only thing that failed was the
OutboundMessagePublisher.java:31 // record of it, and the two must not be confusable.
OutboundMessagePublisher.java:32 boolean sent = false;
OutboundMessagePublisher.java:33 try {
OutboundMessagePublisher.java:34 broker.send(message);
OutboundMessagePublisher.java:35 sent = true;
OutboundMessagePublisher.java:36 } catch (Exception ex) {
OutboundMessagePublisher.java:37 // fail-open: observe with correlationId, delegate durability to outbox/retry,
OutboundMessagePublisher.java:38 // do NOT propagate — the core use case must still succeed.
OutboundMessagePublisher.java:39 observeQuietly(
OutboundMessagePublisher.java:40 () -> dependencyLogger.logFailure(broker.brokerId(), DEPENDENCY_TYPE, "publish", ex));
OutboundMessagePublisher.java:41 }
OutboundMessagePublisher.java:42 if (sent) {
OutboundMessagePublisher.java:43 observeQuietly(
OutboundMessagePublisher.java:44 () -> dependencyLogger.logSuccess(broker.brokerId(), DEPENDENCY_TYPE, "publish"));
OutboundMessagePublisher.java:45 }
OutboundMessagePublisher.java:46 }
OutboundMessagePublisher.java:48 /**
OutboundMessagePublisher.java:49 * Runs an observation, absorbing whatever it throws.
OutboundMessagePublisher.java:50 *
OutboundMessagePublisher.java:51 * <p>Diagnostics are non-authoritative. An appender that is out of disk must not change what the
OutboundMessagePublisher.java:52 * caller believes about the broker.
OutboundMessagePublisher.java:53 */
OutboundMessagePublisher.java:54 private static void observeQuietly(Runnable observation) {
OutboundMessagePublisher.java:55 try {
OutboundMessagePublisher.java:56 observation.run();
OutboundMessagePublisher.java:57 } catch (RuntimeException ignored) {
OutboundMessagePublisher.java:58 // Nothing to report it to: the reporter is what failed.
OutboundMessagePublisher.java:59 }
OutboundMessagePublisher.java:60 }
# 그 데코레이터를 부르는 팬아웃 루프
RoutingNotifier.java:112 @Override
RoutingNotifier.java:113 public void notify(Channel channel, String route, Notification notification) {
RoutingNotifier.java:114 List<String> providerIds = resolveRoute(channel, route);
RoutingNotifier.java:115 Map<String, FailOpenNotificationProvider> channelRegistry =
RoutingNotifier.java:116 registry.getOrDefault(channel, Map.of());
RoutingNotifier.java:117 // FailOpenNotificationProvider.send declares no throws — no try/catch needed.
RoutingNotifier.java:118 // Individual provider failures are observed (logged) inside the decorator
RoutingNotifier.java:119 // and never propagated, so one failure does not block remaining fan-out sends.
RoutingNotifier.java:120 for (String providerId : providerIds) {
RoutingNotifier.java:121 channelRegistry.get(providerId).send(notification);
RoutingNotifier.java:122 }
RoutingNotifier.java:123 }
# 위임 제공자가 던지는 경로에 로거 예외를 겹쳤을 때
probe:26 if (n.equals("warn")) {
probe:29 throw new IllegalStateException("the appender is out of disk");
probe:56 throw new IllegalStateException("provider is down");
probe:65 new FailOpenNotificationProvider(failing(), new FailOpenDependencyLogger(logger(warnThrows)));
probe:70 p.send(null);
probe:71 } catch (RuntimeException ex) {
위임 제공자가 던지는 경로 (fail-open 이 삼켜야 하는 경우)
실패 로거가 정상일 때 debug 0 · warn 1 · 호출자에게 나간 예외 없음
그 예외가 제공자 예외를 달고 있는가 : cause=없음 · suppressed=0
실패 로거도 던질 때 debug 0 · warn 1 · 호출자에게 나간 예외 IllegalStateException: the appender is out of disk
그 예외가 제공자 예외를 달고 있는가 : cause=없음 · suppressed=0
# 그 경로를 고정하는 시험이 있는가
알림 모듈에서 Proxy.newProxyInstance 로 로거를 만드는 자리 : 0 개
메시징 모듈에서 같은 자리 : 1 개
이 데코레이터를 조립하는 시험이 던지게 만드는 대상 :
NotificationAdapterTest.java:79 throw new RuntimeException("provider-failure");
RoutingNotifierTest.java:130 throw new RuntimeException("provider-failure");