Skip to content

Record master as merged into v7 (no file changes) - #125

Merged
christopherread merged 7 commits into
v7from
v7-record-master-merge
Oct 25, 2026
Merged

christopherread merged 7 commits into
v7from
v7-record-master-merge

Conversation

@christopherread

Copy link
Copy Markdown
Owner

Merge with "Create a merge commit". Squashing this PR would undo its purpose.

#124 brought master's content into v7, but it was squash-merged, so its commit has one parent. Git therefore still treated master's 6 commits as unmerged:

The next master merge would have repeated #124's four conflicts.

This PR is a single merge commit made with git merge -s ours origin/master.

  • Parents: it has two, the current v7 and master's tip c0ff537.
  • Files: it changes none; the diff against v7 is empty.
  • After a merge commit: git rev-list origin/v7..origin/master comes back empty. The next master merge then only brings in commits made after this one.

🤖 Generated with Claude Code

christopherread and others added 7 commits October 25, 2026 09:26
* Add v7 'AI native' design doc

Proposes how v7 changes configuration, message registration, handlers,
testing, errors, observability, contracts, packaging and docs so AI
coding agents (and people) can use Obvs correctly first time. Each
change links to its tracking issue in the v7 milestone (#84-#95).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Design doc: frame the async APIs as layers over the observable core

Section 4 now explains why v7 stays observable-first: handlers, RequestAsync
and IAsyncEnumerable are thin adapters over IObservable, Rx stays first
class for stream composition, and analyzer OBVS006 catches Subscribe(async).
Resolves the open question on Rx: it stays in the core package.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Design doc: describe the bus lifetime under dependency injection

Section 1 now covers how the singleton bus is registered and owned, scoped
handlers, repeated AddObvs calls, keyed buses, and why one bus per
container needs a per-bus instance ID in broker-side names instead of the
process ID used by v6.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
MessageSource started its receive loop with Task.Run. The loop blocks for
as long as the subscription lasts, so each subscription held a thread-pool
thread, and Subscribe waited until the loop got one. On CI's small runners,
the NetMQ tests start a dozen subscriptions at once; the pool added threads
slowly, subscribers took over 5 seconds to connect, publishers stopped
waiting for them, and the first messages were dropped. The loop now runs as
a LongRunning task on a dedicated thread.

TestMessageSourceThreading saturates the thread pool and checks that
subscribing doesn't wait for it. It failed before this change.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…hread (#113)

MessageSource passed each message to subscribers synchronously on
RabbitMQ.Client's consumer-dispatch thread. Code running after a message
arrived, including code after awaiting one (the continuation runs inline
there), could deadlock it: disposing the bus closes the connection, which
waits for that same thread. Messages are still deserialized on the
dispatch thread, while the body's buffer is valid, then handed to
subscribers on the task pool, in order.

TestServiceBus.ShouldNotDeadlockWhenASubscriberDisposesTheBus disposes the
bus from a message callback; it timed out before this change.

Backport of the fix in v7 PR #112.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Microsoft's download origin returns 409 for the new SDK 10.0.403 and
runtime 10.0.14, so setup-dotnet fails to install 10.0.x. Go back to
10.0.x once that release downloads.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
MessageSource called observer.OnNext on its consume thread, the task
started by Task.Run in Messages. Disposing the subscription cancels the
token and then waits for that task, so a subscriber that disposed the bus
or its subscription from a message callback waited on itself forever.
Messages are now handed to subscribers on the task pool, in order.

TestMessageSendAndReceive.ShouldNotDeadlockWhenASubscriberDisposesItsSubscription
disposes the subscription from a message callback; the message arrived but
the dispose timed out before this change.

Backport of the fix in v7 PR #119; the same fix for RabbitMQ was #113.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…thread (#122)

MessageSource passed each message to subscribers synchronously on the NMS
session's dispatch thread. Code that ran after awaiting a message could
then run on that thread, and deadlock it by disposing the bus: stopping
the connection waits for the dispatch thread, forever. NMS skips that
wait only for code in the dispatch's own execution context, which an
await continuation isn't. Messages are now handed to subscribers on the
task pool, in order.

TestServiceBus.ShouldNotDeadlockWhenCodeAfterAwaitingAMessageDisposesTheBus
hung before this change. Five TestMessageSource tests now wait for
delivery instead of expecting it on the listener's thread. CI runs the
ActiveMQ broker tests against apache/activemq-classic.

Backport of the fix in v7 PR #121.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Records master's commits up to c0ff537 as merged, without changing any files.
Their content is already on v7: #124 brought it in, but was squash-merged, so git still
treated them as unmerged and the next master merge would have repeated its conflicts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@christopherread christopherread added this to the v7 milestone Oct 25, 2026
@christopherread
christopherread merged commit f3fc238 into v7 Oct 25, 2026
@christopherread
christopherread deleted the v7-record-master-merge branch October 25, 2026 22:56
christopherread added a commit that referenced this pull request Oct 26, 2026
GitVersion 6's Mainline strategy throws "Cannot find the base commit of merged branch"
on f3fc238, the merge commit #125 added to v7, so CI failed at Determine Version on v7
and every branch from it. Ignoring that commit lets it calculate a version again.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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