What determinism means

localhost2137 does not have a “make everything deterministic” switch. A useful test names the inputs it controls and leaves the rest visible.

This Stripe semantic test compares the same 30-day billing transition in two fresh worlds. It is source-backed evidence from the plugin suite, not a fragment to paste into an application test.

	it("uses the same exact 30-day renewal boundaries in pinned and real-offset modes", async () => {
		const real = await startRuntime(createStripePlugin(), {
			clock: { mode: "real" },
			webhookUrl: null,
		});
		const realInstance = await real.createInstance();
		const realSubscription = await createBillingWorld(realInstance.stripe);
		const [realInitial] = await realInstance.stripe.listInvoices({
			subscriptionId: realSubscription.id,
		});
		if (!realInitial) throw new TypeError("Expected a real-mode initial invoice.");
		const pinned = await startRuntime(createStripePlugin(), {
			clock: { mode: "pinned", startAt: realInitial.periodStart },
			webhookUrl: null,
		});
		const pinnedInstance = await pinned.createInstance();
		try {
			const pinnedSubscription = await createBillingWorld(pinnedInstance.stripe);
			await Promise.all([pinnedInstance.clock.advance("30d"), realInstance.clock.advance("30d")]);
			const pinnedInvoices = await pinnedInstance.stripe.listInvoices({
				subscriptionId: pinnedSubscription.id,
			});
			const realInvoices = await realInstance.stripe.listInvoices({
				subscriptionId: realSubscription.id,
			});
			expect(pinnedInvoices).toHaveLength(2);
			expect(realInvoices).toHaveLength(2);
			expect(
				pinnedInvoices.map(({ periodEnd, periodStart }) => ({ periodEnd, periodStart })),
			).toEqual(realInvoices.map(({ periodEnd, periodStart }) => ({ periodEnd, periodStart })));
			for (const invoice of [...pinnedInvoices, ...realInvoices]) {
				expect(Date.parse(invoice.periodEnd) - Date.parse(invoice.periodStart)).toBe(
					BILLING_PERIOD_MS,
				);
			}
			expect(await pinnedInstance.stripe.listEvents({})).toEqual(
				await realInstance.stripe.listEvents({}),
			);
		} finally {
			await Promise.all([pinnedInstance.destroy(), realInstance.destroy()]);
		}
	});

• Controlled: plugin version, configuration, billing inputs, separate instance state, one explicit 30d transition, and cleanup.
• Intentionally uncontrolled: the real world's initial wall-clock instant. The pinned world starts at the period boundary observed there, then the test compares invoices and events.

That proves one Stripe invariant: both clock modes reconcile the same exact 30-day billing windows from the same logical starting instant. It does not prove that application clocks, random values, untracked promises, or external Stripe behavior are repeatable.

Runtime mechanisms have defined scopes

Each mechanism has a narrow owner:

Pinned time is not frozen machine time. A plugin must read its context clock and implement its time-derived transitions. Real clock mode is sometimes necessary, for example when an SDK checks a callback timestamp against wall time.

idle() is also not “wait until Node has no work.” It reports completion or failure only for tasks registered with that instance. Application queues need their own synchronization boundary.

Four separate claims

These properties do not imply one another. A repeatable emulator can return the wrong error every time. An isolated world can still model an outdated provider rule. A passing SDK call proves only the installed version and path the test actually exercised.

localhost2137 currently supplies no deterministic randomness facility. Do not infer stable IDs or ordering from the runtime. Those are plugin semantics and must be documented and tested by the plugin when an application depends on them.

For executable application-level time control, continue with Virtual time and asynchronous work. For evidence scope, see Provider compatibility and Choose the right test boundary.