Infrastructure Messages

Since v3.5 the bus is a message-driven system: every mutation of the bus itself — registration, middleware, locking, namespaces — is performed by executing a built-in infrastructure message through postboy.exec(...). The corresponding convenience methods on PostboyService (lock, unlock, addMiddleware, removeMiddleware, addNamespace, eliminateNamespace, unregister) were removed.

Two consequences worth knowing:

Infrastructure messages are regular executors: they declare their own static ID and run through the Execute stage of the middleware pipeline. A domain-gating middleware should filter them out with canHandle.
Everything scriptable on the bus composes the same way application commands do.

Overview

Group	Message	Purpose
Registration	`ConnectMessage<T>`	register a message subject (+ optional delivery pipe)
Registration	`ConnectExecutor<E, T>`	register an executor handler function
Registration	`ConnectHandler<E, R>`	register an executor handler object
Registration	`DisconnectMessage`	unregister by static ID; completes the subject
Pipeline	`AddMiddleware`/`RemoveMiddleware`	add/remove middleware (removal is by instance identity and calls `dispose()`)
Locking	`LockMessage<T>`/`UnlockMessage<T>`	mute/unmute a type's delivery
Namespaces	`AddNamespace`/`EliminateNamespace`	create/tear down a namespaced registrator group

Registration group

Covered in depth in Registration:

postboy.exec(new ConnectMessage(OrderPlacedEvent, new Subject<OrderPlacedEvent>()));
postboy.exec(new ConnectExecutor(GetUserNameExecutor, (e) => resolve(e)));
postboy.exec(new DisconnectMessage(OrderPlacedEvent.ID));

DisconnectMessage completes the registered Subject (subscriber streams end) and drops an executor handler registered under the same ID. Further fire/sub of the type throws.

Pipeline group

postboy.exec(new AddMiddleware(new LoggingMiddleware()));
postboy.exec(new RemoveMiddleware(loggingMiddleware)); // same instance; calls its dispose()

Adding the same instance twice runs its hooks twice. See Middleware.

Locking group

postboy.exec(new LockMessage(SensitiveEvent));

A locked type's delivery via fire and fireCallback is silently skipped: no error, no notification, registration and sub keep working, middleware hooks still run. Treat a locked message as a no-op, not an error — and never lock IDs you don't own: to their subscribers a locked type looks exactly like data loss.

Namespaces group

const registrator = postboy.exec(new AddNamespace('orders'));
// registrator is a PostboyAbstractRegistrator — record on it, then:
postboy.exec(new EliminateNamespace('orders'));

AddNamespace returns the created registrator (repeating the call with the same name returns the same instance). EliminateNamespace runs its down() — one DisconnectMessage per recorded ID. Namespaces scope lifecycle, not message identity; see Namespaces.

Removed service methods

Removed (≤3.4)	Replacement
`lock(Type)`/`unlock(Type)`	`LockMessage`/`UnlockMessage`
`addMiddleware(mw)`/`removeMiddleware(mw)`	`AddMiddleware`/`RemoveMiddleware`
`addNamespace(ns)`	`AddNamespace`
`eliminateNamespace(ns)`	`EliminateNamespace`
`unregister(Type)`	`DisconnectMessage(Type.ID)`

Exact signatures: API reference — infrastructure messages.

Next steps

Registration — the Connect messages in application context.
Middleware and Namespaces — the two groups they serve.

07 September 2026