Skip to content

chore(release): version packages - #24

Merged
dbjpanda merged 1 commit into
mainfrom
changeset-release/main
Sep 26, 2026
Merged

dbjpanda merged 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies []:

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies []:

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies [1cb1a7c]:

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies []:

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies []:

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies [1cb1a7c]:

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

  • #23 1cb1a7c Thanks @dbjpanda! - Fix drivers that could never restart after stop().

    Every component driver carries a stopped guard so an in-flight pass cannot resurrect the loop after
    teardown. stop() set it and nothing cleared it, so a later start() on the same instance
    re-subscribed to commits and then ignored all of them: no dispatch, no sweep, no error logged.

    The fleet restarts drivers on the same instances. Drivers follow the default shard, so a node that
    released that shard stopped them, and if it later re-acquired the shard after a peer died, its
    scheduler, triggers, notifications and reapers came back dead. That is the intermittent fleet e2e
    failure "tick chain to resume on the survivor": which node was the survivor depended on rendezvous
    hashing over freshly chosen ports.

    start() now clears the guard. The runtime's own driversStarted flag was fixed for the same reason
    earlier; this is the same defect one layer down.

  • Updated dependencies []:

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

Patch Changes

@concile/[email protected]

@concile/[email protected]

@concile/[email protected]

@concile/[email protected]

@concile/[email protected]

@concile/[email protected]

@concile/[email protected]

Patch Changes

[email protected]

Patch Changes

[email protected]

Patch Changes

[email protected]

Patch Changes

@vercel

vercel Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
concile Ready Ready Preview Sep 24, 2026 10:31pm UTC

@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 048e8f2 to 2b448d7 Compare September 24, 2026 22:29
@dbjpanda
dbjpanda merged commit d883b99 into main Sep 26, 2026
4 of 5 checks passed
@dbjpanda
dbjpanda deleted the changeset-release/main branch September 26, 2026 20:24

This branch was successfully deployed

1 active deployment
Preview — 2b448d7a Deployed Sep 24, 2026 by vercel[bot]
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.

1 participant