Skip to content

chore: Coordinate PR merge order and integration dependencies #158

Open

Description

@juherr

Context

Several open PRs introduce related fixes and features across the WAMP transport, connection lifecycle, observability, and security layers.

Some PRs are explicitly stacked on others, while independent changes modify the same components and may introduce integration conflicts or regressions.

This tracking issue proposes a coherent merge sequence to:

  • Make reviews easier by keeping related changes together.
  • Respect actual Git dependencies.
  • Reduce repeated rebases and merge conflicts.
  • Stabilize concurrency-sensitive code before extending it.
  • Preserve existing behavior when combining independent changes.

The sequence below is a proposal, not a strict requirement. Independent PRs can progress in parallel.

Proposed merge batches

Batch 1 — Stabilize the WAMP client

Rationale: Establish reliable client behavior before integrating additional client-side features.

Integration notes:

Batch 2 — Stabilize WebSocket endpoints and connection lifecycle

Dependencies:

Rationale: Ensure endpoint routing, connection registration, reconnection, and event notifications are reliable before introducing additional admission and security mechanisms.

Integration notes:

  • Preserve per-station event ordering.
  • Ensure listener exceptions cannot leave registered connections unusable.
  • Check that per-station locks are eventually released.
  • Validate concurrent connections and shutdown behavior.

Batch 3 — Server observability and security

Confirmed dependency chain:

#128 → #134 → #154 → #157

These are stacked PRs and should be merged in this order.

Integration notes:

Batch 4 — Client observability and configuration

Dependencies and interactions:

Integration notes:

CI and merge readiness

At the time of this proposal, the latest builds of these PRs were failing:

These failures may be related to existing concurrency issues, particularly those addressed by #147, but that has not been demonstrated for every case.

Before merging the affected PRs:

  • Rebase on the updated dev branch.
  • Re-run the full build.
  • Investigate any remaining failures rather than assuming they are flaky.
  • Repeat concurrency-sensitive tests where appropriate.
  • Verify that the final integration retains the regression tests from each PR.

Merge strategy

Suggested workflow:

  1. Review and merge each PR independently.
  2. Rebase stacked descendants after their parent PR merges.
  3. Review the resulting reduced diff rather than the original stacked diff.
  4. Run CI after each integration.
  5. Review combined behavior wherever independently developed PRs modify the same execution path.
  6. Keep this issue updated as dependencies or priorities evolve.

The batches represent logical integration milestones, not release boundaries.

Maintainer feedback

@pbourseau — Does this grouping and order make sense from a maintainer's perspective?

In particular, feedback would be useful on:

The goal is to make the remaining PRs easier to review and integrate without introducing unnecessary process overhead.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions