fix: define transactional outbox store contract - #1130
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (5)
📝 WalkthroughWalkthrough
Changes
추정 코드 리뷰 노력🎯 5 (Critical) | ⏱️ ~90+ minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
📊 Benchmark Results❌ Some benchmarks failed Gate failures
Updated: 2026-06-30T22:36:13.293Z · Commit: ae6ed90 |
There was a problem hiding this comment.
Actionable comments posted: 13
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/problem-code-registry.json`:
- Around line 7655-7684: The registry entries for
outbox-core/failure-metadata-missing and unit-of-work-context-invalid are
incorrectly marked as conditionally retryable 500s with retry-oriented recovery
text, which can mislead consumers. Update the problem definitions referenced by
OutboxProblems so these cases are clearly non-retryable invariant violations,
and revise the recovery metadata for both entries to use failure/abort-oriented
cause, userAction, and operatorAction wording instead of retry guidance.
In
`@packages/docs/src/content/docs/api/outbox-core/src/classes/InMemoryTransactionalOutboxStore.md`:
- Line 8: The class description for InMemoryTransactionalOutboxStore is using
wording that describes the TransactionalOutboxStore contract instead of the
concrete implementation. Update the generated doc comment so
InMemoryTransactionalOutboxStore is described as the in-memory transactional
outbox store implementation, and keep the provider-neutral contract wording only
on TransactionalOutboxStore to avoid confusing the API docs.
In
`@packages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxDispatchProblemOptions.md`:
- Around line 8-10: The description for OutboxDispatchProblemOptions is a
copy-pasted storage-contract blurb and does not match the actual type; update
the markdown generated for this type alias to describe its real purpose as
options used when creating a Problem for dispatch failures. Use the source
definition in OutboxProblems and align the summary text with the
OutboxDispatchProblemOptions symbol so the generated docs reflect the actual API
meaning.
In
`@packages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxDispatchResultMetadata.md`:
- Around line 8-11: The type description for OutboxDispatchResultMetadata is
incorrect and appears to be copied from a storage contract type. Update the
documentation text in OutboxDispatchResultMetadata so it describes this object
as the dispatch result metadata container for provider message IDs and related
metadata, not as a provider-neutral transactional outbox storage contract.
In
`@packages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureMetadata.md`:
- Around line 8-11: The description for OutboxFailureMetadata is incorrect and
looks copied from a storage contract. Update the documentation for
OutboxFailureMetadata to describe the retry/failure metadata it actually
represents: retryable, terminal, attempt counts, max attempts, failed at, and
next visible at, rather than a provider-neutral storage contract.
In
`@packages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureRecord.md`:
- Around line 8-11: The description for OutboxFailureRecord is incorrect and
appears to be copied from a storage-contract type. Update the markdown in the
OutboxFailureRecord type alias doc so it clearly describes this type as a
persisted failure record containing Problem.toJSON() output and retry metadata,
not as a provider-neutral storage contract. Use the OutboxFailureRecord
heading/context in the generated docs to replace the misleading summary with
accurate wording.
In `@packages/outbox-core/src/index.ts`:
- Around line 4-56: The barrel exports in index.ts are mixed with type exports,
making the public API harder to scan; reorganize the exports so runtime exports
are grouped by category first and all export type blocks are moved to the end.
Keep the existing symbols from OutboxProblems, conformance, and
InMemoryTransactionalOutboxStore, but reorder them consistently so the file
follows the index.ts guideline and has a clear runtime-then-types structure.
In `@packages/outbox-core/src/libs/conformance.ts`:
- Around line 147-158: Update the conformance checks in conformance.ts so they
verify the specific Problem subtype, not just that a rejection happened. Replace
the generic assertRejects usage in the malformed Unit of Work context and
failure metadata cases with a predicate/constructor-based assertion that expects
OutboxUnitOfWorkContextProblem and OutboxFailureMetadataProblem respectively,
using the existing test helpers around store.record and the failure-metadata
validation cases. Ensure these tests fail when a generic Error or the wrong
Problem subclass is thrown.
In `@packages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.ts`:
- Around line 181-194: In runInUnitOfWork, the current commit path can overwrite
a previously committed rootState when two units start from the same snapshot.
Update InMemoryTransactionalOutboxStoreClient handling in
InMemoryTransactionalOutboxStore.runInUnitOfWork to either serialize commits or
add optimistic conflict detection before assigning this.rootState =
cloneState(client.state), so concurrent commits do not cause a lost update and
transaction boundaries remain consistent.
- Around line 218-242: The custom id path in InMemoryTransactionalOutboxStore is
overwriting existing records when options.id matches a different record, which
can corrupt the idempotency index. Update the record creation flow to detect a
record.id collision before state.records.set and reject it with a Problem
subclass instead of replacing the existing entry; make sure the check is done
alongside the existing scopedKey/idByIdempotencyScope handling in the same
insert logic.
- Around line 316-342: The retry exhaustion logic in
InMemoryTransactionalOutboxStore should not trust failure.maxAttempts from the
incoming failure metadata, since dispatcher-supplied Problem extensions can
bypass the record’s actual retry budget. Update the retry/terminal evaluation
and the record update in the failure handling path to use the stored retry state
from the existing record (for example record.retry.maxAttempts) as the source of
truth, while still preserving normalized failure details for retryable/terminal
flags and timestamps.
- Around line 45-47: The cloneRecord helper currently performs only a shallow
copy, so nested payload, metadata, and dispatchResult.metadata objects can still
be shared between stored outbox records and callers. Update cloneRecord in
InMemoryTransactionalOutboxStore to deep-clone those nested structures when
copying records, and make sure the store’s read/write paths that use cloneRecord
preserve isolation between the internal state and any returned intent or record
objects.
In `@packages/outbox-core/vitest.config.ts`:
- Around line 4-8: The Vitest configuration is too broad and does not enforce
the repo’s required test location convention. Update the test include setting in
vitest.config.ts so it only matches the mandatory src/tests/[ClassName].spec.ts
path pattern, and remove the looser src/**/*.test.ts / src/**/*.spec.ts
globbing. Keep the change focused on the test.include value in the test config
object so only the approved tests are picked up.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 204d3d69-4557-48bd-bcd9-ac1ecf8d5b83
⛔ Files ignored due to path filters (2)
packages/problems-core/src/generated/problem-code-registry.tsis excluded by!**/generated/**pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (59)
.changeset/outbox-core-contract.md.github/workflows/ci.ymlREADME.mddocs/package-catalog.jsondocs/package-docs-report.mddocs/problem-code-registry.jsonpackages/docs/astro.config.mjspackages/docs/package.jsonpackages/docs/src/content/docs/api/outbox-core/src/classes/InMemoryTransactionalOutboxStore.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxDispatchProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxFailureMetadataProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxUnitOfWorkContextProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/functions/createOutboxFailureProblemExtensions.mdpackages/docs/src/content/docs/api/outbox-core/src/functions/createTransactionalOutboxStoreContractSuite.mdpackages/docs/src/content/docs/api/outbox-core/src/functions/readOutboxFailureMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/interfaces/TransactionalOutboxStore.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/ClaimBatchOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/ClaimedOutboxRecord.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/DispatchResult.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/InMemoryTransactionalOutboxStoreClient.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/InMemoryTransactionalOutboxStoreState.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxClaim.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxDispatchProblemOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxDispatchResultMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureProblemExtensions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureRecord.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxIntent.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecord.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecordOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecordStatus.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRetryMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRetryOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxSourceReference.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxTenantBoundary.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxTraceContext.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/TransactionalOutboxStoreContext.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/TransactionalOutboxStoreContractCase.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/TransactionalOutboxStoreContractOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/TransactionalOutboxStoreContractSuite.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_DISPATCH_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_FAILURE_METADATA_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_UNIT_OF_WORK_CONTEXT_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/problems-core/src/classes/Problem.mdpackages/docs/src/content/docs/en/guides/getting-started.mdxpackages/docs/src/content/docs/en/index.mdxpackages/docs/src/content/docs/en/reference/problem-recovery-cookbook.mdpackages/docs/tsconfig.typedoc.jsonpackages/outbox-core/README.mdpackages/outbox-core/package.jsonpackages/outbox-core/src/index.tspackages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.tspackages/outbox-core/src/libs/conformance.tspackages/outbox-core/src/libs/problems/OutboxProblems.tspackages/outbox-core/src/libs/types.tspackages/outbox-core/src/tests/TransactionalOutboxStore.spec.tspackages/outbox-core/tsconfig.jsonpackages/outbox-core/vitest.config.tspublic-api-surface.snapshot.json
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.ts (1)
184-219: 🗄️ Data Integrity & Integration | 🔴 Critical | 🏗️ Heavy lift
runInUnitOfWork커밋이markDispatched/markFailed/clear()의 동시 변경을 덮어쓸 수 있습니다.
runInUnitOfWork는 시작 시점에rootState를 복제해client.state로 작업하다가, 끝날 때this.rootState = cloneState(client.state)로 rootState 전체를 통째로 교체합니다. 반면markDispatched,markFailed,clear()는unitOfWorkQueue를 거치지 않고this.rootState를 직접 읽고 씁니다.따라서 UoW가 실행 중인 동안(예:
fn내부에서await로 양보하는 사이)markDispatched나markFailed가this.rootState.records를 직접 변경하면, 해당 변경은 UoW 커밋 시점의 통째 교체(this.rootState = cloneState(client.state))에 의해 조용히 사라집니다(lost update). PR 목표인 "claiming must support safe concurrent dispatch semantics"와 충돌하는 동작입니다. 이는 이미 해결된 "두 UoW 간 lost update" 이슈와는 별개의, UoW와 비-UoW 변경 메서드 간의 새로운 race입니다.모든 상태 변경 메서드(
record/claimBatch/markDispatched/markFailed/clear)를 동일한 직렬화 큐를 통하도록 통일하는 것을 권장합니다.🔒 제안 수정 방향 (모든 변경 작업을 동일 큐로 직렬화)
async runInUnitOfWork<T>( fn: ( context: TransactionalOutboxStoreContext<InMemoryTransactionalOutboxStoreClient>, ) => Promise<T>, ): Promise<T> { - let release: () => void = () => {}; - const previous = this.unitOfWorkQueue; - this.unitOfWorkQueue = new Promise<void>((resolve) => { - release = resolve; - }); - - await previous; - - const client: InMemoryTransactionalOutboxStoreClient = { - state: cloneState(this.rootState), - }; - this.clients.add(client); - - try { - const result = await fn({ client }); - this.rootState = cloneState(client.state); - return result; - } finally { - this.clients.delete(client); - release(); - } + return this.enqueue(async () => { + const client: InMemoryTransactionalOutboxStoreClient = { + state: cloneState(this.rootState), + }; + this.clients.add(client); + try { + const result = await fn({ client }); + this.rootState = cloneState(client.state); + return result; + } finally { + this.clients.delete(client); + } + }); } + + private enqueue<T>(task: () => Promise<T>): Promise<T> { + const run = this.unitOfWorkQueue.then(task, task); + this.unitOfWorkQueue = run.then( + () => undefined, + () => undefined, + ); + return run; + } clear(): void { - this.rootState = createEmptyState(); + void this.enqueue(async () => { + this.rootState = createEmptyState(); + }); }
markDispatched/markFailed도 동일하게 본문 전체를this.enqueue(async () => { ... })로 감싸면 됩니다.Also applies to: 309-325, 327-372
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.ts` around lines 184 - 219, `runInUnitOfWork` currently snapshots and later overwrites `rootState`, while `markDispatched`, `markFailed`, and `clear()` mutate `rootState` directly, so concurrent updates can be lost. Make the state-changing methods in `InMemoryTransactionalOutboxStore` use the same serialized queue/critical section as `runInUnitOfWork` so all writes are ordered consistently. Update `record`, `claimBatch`, `markDispatched`, `markFailed`, and `clear` to go through the shared enqueue path, and keep `rootState` updates within that single serialization mechanism.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@packages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.ts`:
- Around line 184-219: `runInUnitOfWork` currently snapshots and later
overwrites `rootState`, while `markDispatched`, `markFailed`, and `clear()`
mutate `rootState` directly, so concurrent updates can be lost. Make the
state-changing methods in `InMemoryTransactionalOutboxStore` use the same
serialized queue/critical section as `runInUnitOfWork` so all writes are ordered
consistently. Update `record`, `claimBatch`, `markDispatched`, `markFailed`, and
`clear` to go through the shared enqueue path, and keep `rootState` updates
within that single serialization mechanism.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 15d5343c-9ed6-4168-9ebf-463be215407e
⛔ Files ignored due to path filters (2)
packages/problems-core/src/generated/problem-code-registry.tsis excluded by!**/generated/**pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (48)
.github/workflows/ci.ymlREADME.mddocs/package-catalog.jsondocs/package-docs-report.mddocs/problem-code-registry.jsonpackages/docs/astro.config.mjspackages/docs/src/content/docs/api/outbox-core/src/classes/InMemoryTransactionalOutboxStore.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxDispatchProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxFailureMetadataProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxRecordIdConflictProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/classes/OutboxUnitOfWorkContextProblem.mdpackages/docs/src/content/docs/api/outbox-core/src/functions/createOutboxFailureProblemExtensions.mdpackages/docs/src/content/docs/api/outbox-core/src/functions/createTransactionalOutboxStoreContractSuite.mdpackages/docs/src/content/docs/api/outbox-core/src/functions/readOutboxFailureMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/ClaimBatchOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/ClaimedOutboxRecord.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/DispatchResult.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxClaim.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxDispatchProblemOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxDispatchResultMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxFailureRecord.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxIntent.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecord.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecordOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecordStatus.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRetryMetadata.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRetryOptions.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxSourceReference.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxTenantBoundary.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxTraceContext.mdpackages/docs/src/content/docs/api/outbox-core/src/type-aliases/TransactionalOutboxStoreContext.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_DISPATCH_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_FAILURE_METADATA_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_RECORD_ID_CONFLICT_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/outbox-core/src/variables/OUTBOX_UNIT_OF_WORK_CONTEXT_PROBLEM_CODE.mdpackages/docs/src/content/docs/api/problems-core/src/classes/Problem.mdpackages/docs/src/content/docs/api/problems-core/src/variables/CROCO_PROBLEM_CODE_REGISTRY.mdpackages/docs/src/content/docs/en/index.mdxpackages/docs/src/content/docs/en/reference/problem-recovery-cookbook.mdpackages/outbox-core/src/index.tspackages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.tspackages/outbox-core/src/libs/conformance.tspackages/outbox-core/src/libs/problems/OutboxProblems.tspackages/outbox-core/src/libs/types.tspackages/outbox-core/vitest.config.tspublic-api-surface.snapshot.jsonscripts/problem-registry.mts
💤 Files with no reviewable changes (7)
- packages/docs/src/content/docs/api/outbox-core/src/functions/createOutboxFailureProblemExtensions.md
- packages/docs/src/content/docs/api/outbox-core/src/type-aliases/ClaimedOutboxRecord.md
- packages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRecordStatus.md
- packages/docs/src/content/docs/api/outbox-core/src/functions/readOutboxFailureMetadata.md
- packages/docs/src/content/docs/api/outbox-core/src/type-aliases/TransactionalOutboxStoreContext.md
- packages/docs/src/content/docs/api/outbox-core/src/type-aliases/DispatchResult.md
- packages/docs/src/content/docs/api/outbox-core/src/type-aliases/OutboxRetryOptions.md
Member
Author
|
Addressed the remaining lost-update review finding in |
Member
Author
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
packages/outbox-core/src/tests/TransactionalOutboxStore.spec.ts (1)
140-159: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Deferred/createDeferred중복 정의.
packages/outbox-core/src/libs/conformance.ts:755-774와 완전히 동일한 헬퍼가 이 파일에도 새로 추가되었습니다. 공유 테스트 유틸리티 모듈로 추출해 두 파일에서 import하는 것을 권장합니다(상세 제안은 conformance.ts 코멘트 참조).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/outbox-core/src/tests/TransactionalOutboxStore.spec.ts` around lines 140 - 159, Remove the duplicated Deferred/createDeferred helper from TransactionalOutboxStore.spec and reuse the shared test utility instead; the same helper already exists in conformance.ts, so extract or import it from a common test-utils module and update the spec to reference that shared symbol rather than defining it locally.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/outbox-core/src/libs/conformance.ts`:
- Around line 747-774: The `assertDefined` and `createDeferred` helpers in
`conformance.ts` are duplicated in the transactional outbox spec, so extract
them into a shared test utility module and import them from both places to keep
the implementations aligned. While doing so, update the guard failures in
`assertDefined` and `createDeferred` to throw a `Problem` subclass instead of
generic `Error`, and keep the existing symbols (`assertDefined`, `Deferred`,
`createDeferred`) as the main integration points for the refactor.
In `@packages/outbox-core/src/tests/TransactionalOutboxStore.spec.ts`:
- Line 123: This test assertion in TransactionalOutboxStore.spec should follow
the async error-checking guideline by using Vitest’s
rejects.toThrow(OutboxUnitOfWorkContextProblem) instead of
rejects.toBeInstanceOf(...). Update the failing expectation in the relevant
promise rejection test to assert the thrown error type with toThrow, keeping the
existing async/await pattern and matching the other error-case tests in this
suite.
---
Duplicate comments:
In `@packages/outbox-core/src/tests/TransactionalOutboxStore.spec.ts`:
- Around line 140-159: Remove the duplicated Deferred/createDeferred helper from
TransactionalOutboxStore.spec and reuse the shared test utility instead; the
same helper already exists in conformance.ts, so extract or import it from a
common test-utils module and update the spec to reference that shared symbol
rather than defining it locally.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7c07419f-540a-475a-a21e-c1a1c49be586
⛔ Files ignored due to path filters (1)
packages/problems-core/src/generated/problem-code-registry.tsis excluded by!**/generated/**
📒 Files selected for processing (8)
docs/problem-code-registry.jsonpackages/docs/src/content/docs/api/outbox-core/src/classes/InMemoryTransactionalOutboxStore.mdpackages/docs/src/content/docs/api/problems-core/src/variables/CROCO_PROBLEM_CODE_REGISTRY.mdpackages/docs/src/content/docs/en/reference/problem-recovery-cookbook.mdpackages/outbox-core/src/libs/InMemoryTransactionalOutboxStore.tspackages/outbox-core/src/libs/conformance.tspackages/outbox-core/src/tests/TransactionalOutboxStore.spec.tspublic-api-surface.snapshot.json
Member
Author
|
@coderabbitai review |
✅ Action performedReview finished.
|
Member
Author
|
@coderabbitai review |
✅ Action performedReview finished.
|
Member
Author
|
@coderabbitai review |
✅ Action performedReview finished.
|
kang-heewon
dismissed stale reviews from coderabbitai[bot] and coderabbitai[bot]
June 30, 2026 23:09
Superseded by later commits and current-head CodeRabbit review fc776a68 with no actionable comments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1092
Summary
@croco/outbox-corewith the provider-neutralTransactionalOutboxStorecontract, outbox record/claim/failure types, and Unit of Work context boundary.Verification
COREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm --filter @croco/outbox-core testCOREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm --filter @croco/outbox-core typecheckCOREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm --filter @croco/outbox-core buildCOREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm --filter @croco/docs docs:buildCOREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm checkCOREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm typecheckCOREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack pnpm changeset-required:check -- --base origin/trunk --head HEADgit diff --checkandgit diff --cached --checkLocal full
pnpm testis blocked in this worktree by@croco/tx-drizzleRealDb tests failing to load a localbetter-sqlite3native binding under the current Node/toolchain; focused outbox tests pass.Summary by CodeRabbit
@croco/outbox-core패키지가 추가되어 트랜잭셔널 아웃박스 저장소의 provider-neutral 계약과 메모리 기반 구현을 제공합니다.