Skip to content

R10/R11 hardening fixes batch (correctness + atomicity safety net) #24

@zfarrell

Description

@zfarrell

Context

This is one ticket in a series carrying forward #12 foundation work. Read #12 first for repo context.

The fork went through ten review cycles (R1–R11) and accumulated a substantial set of correctness, atomicity, and overflow-safety fixes. Some are tied to specific feature workstreams and travel with those tickets (#17/#18/#19/#20). The ones that don't have a clear home — generic safety net improvements — live here.

This ticket exists so the safety improvements don't get lost when the feature tickets are extracted into focused PRs.

Reference branch

ducklake-features/integration — search commit log for R10-S-* and R11-S-* prefixes. Read docs/2026-03-03-retrospective-r1-r5.md and docs/2026-03-05-retrospective.md for the design intent.

Specific fixes to port (verify each is still applicable after #12 rebase)

Numbered by their R*-S-* reference in the branch commit log:

Scope

  1. For each fix above, check whether it's already on the rebased branch (most should be) — confirm don't re-do.
  2. For each fix that's tied to a specific feature ticket (DELETE physical execution (MOR delete files) #17/UPDATE physical execution (MOR delete + insert) #18/MERGE physical execution (INSERT/UPDATE/DELETE atomic) #19/ALTER/DROP/CREATE schema evolution DDL #20/CDC table functions (with cdc_common duplicate-column bug fix) #21/Type system & inlined-data parsing (merge with upstream overlap) #23), confirm the feature ticket actually pulled it in. If not, this ticket is the safety net.
  3. The remaining fixes (R10-S-007, R11-S-007, R11-S-012, R11-S-018, R11-S-021, R11-S-022, R11-S-025, R11-S-028, R11-S-030) don't belong to a single feature ticket — port them here.

Acceptance criteria

Dependencies

Out of scope

  • Reviewing the design choices behind each fix — they were already reviewed in cycles R1–R11
  • Adding new safety improvements that weren't in the R10/R11 cycle — separate effort

Notes

  • The fork's review-cycle docs in docs/ describe each finding's rationale. Read the relevant doc before porting any non-obvious fix.
  • Several of these are 1-3 line changes; do not over-engineer.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions