chore(inspector): add back database tab

[NathanFlurry]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[railway-app]

🚅 Deployed to the rivet-pr-4255 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	❌ Build Failed (View Logs)	Web	Feb 22, 2026 at 4:52 am
mcp-hub	✅ Success (View Logs)	Web	Feb 22, 2026 at 4:50 am
frontend-cloud	❌ Build Failed (View Logs)	Web	Feb 22, 2026 at 4:50 am
frontend-inspector	❌ Build Failed (View Logs)	Web	Feb 22, 2026 at 4:50 am
ladle	❌ Build Failed (View Logs)	Web	Feb 22, 2026 at 4:50 am

[NathanFlurry]

• chore: multiplayer cookbook patterns #4261 : 2 dependent PRs (#4266 , #4268 )
• docs: document queue with interval pattern #4265
• chore(rivetkit): migrate to sqlite instance per-actor for concurrency optimizations #4264
• docs: workflows #4256
• chore(rivetkit): update conns to be hibernatable #4260
• chore(inspector): add back database tab #4255 👈 (View in Graphite)
• chore: impl canInvoke for matchmaker #4253
• chore: multiplayer cookbook #4200 : 1 other dependent PR (#4201 )
• feat(dashboard): bring new tabs back #4249
• fix(rivetkit): fix sqlite teardown logic #4259
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

PR Review: chore(inspector): add back database tab

This PR does two distinct things: (1) restores the Database tab to the actor inspector UI, and (2) refactors access control from a single canInvoke hook to per-event/queue canSubscribe/canPublish hooks. The refactor is the substantial part.

---

Bugs

Dead code in getValidationSchema (schema.ts)

The two raw if blocks added after the isEventSchemaDefinition and isQueueSchemaDefinition guards are unreachable:

if (isEventSchemaDefinition(schema)) { return schema.schema; }  // catches { schema: defined }
if (isQueueSchemaDefinition(schema)) { return schema.message; } // catches { message: defined, non-event }

// These two never execute — the conditions above already cover them
if (typeof schema === 'object' && 'schema' in schema && ...) { ... }
if (typeof schema === 'object' && 'message' in schema && ...) { ... }

These should be removed.

Indentation regression in instance/mod.ts

The return await this.runInTraceSpan(...) block inside handleRawRequest gained an extra indent level in this diff, making it misaligned relative to the surrounding method bodies. This appears to be a reformat artifact.

Indentation regression in registry.ts

The newly added accessControlNoQueuesActor lines use inconsistent triple-tab indentation that doesn't match the enclosing actors object.

---

Design / API concerns

Unused generic parameter on QueueSchemaConfig

export type QueueSchemaConfig<TContext = any> = Record<string, QueueSchema>;

TContext is declared but not threaded into QueueSchema, so it has no effect. Either propagate it (to match the treatment of EventSchemaConfig<TContext>) or remove it.

canInvoke removal is a breaking change with no migration path

canInvoke was a public API that enabled per-action access control at the connection level. The new model moves authorization to per-event canSubscribe and per-queue canPublish, but there is no equivalent replacement for per-action authorization. Callers who relied on canInvoke to restrict specific action calls per-connection have no fine-grained alternative. This deserves a migration note (e.g., in the PR description or docs).

Raw WebSocket authorization silently dropped

assertCanInvokeWebSocket was removed from router-websocket-endpoints.ts with no replacement. Raw WebSocket connections now rely solely on onBeforeConnect. This is a behavioral change that should be explicitly documented.

onBeforeConnect logic in access-control fixture inverts semantics

The old canInvoke check was deny-by-default (allow only if === true); the new onBeforeConnect throws only if the flag is explicitly === false (allow-by-default). The tests at lines 158–213 that verify HTTP request / WebSocket denial should be confirmed to still exercise the right path under the new semantics.

---

Minor

Undefined event warning could use a comment

In conn/mod.ts and contexts/base/actor.ts, sending/broadcasting an event with no matching schema entry now emits a warning rather than throwing. The new test confirms this is intentional, but a one-line comment at the warn site would prevent future readers from treating it as an oversight.

---

What looks good

• Granular canSubscribe/canPublish per event/queue is a cleaner design than the monolithic canInvoke discriminated union.
• Silently completing queue sends to undefined queues (when a queue config is present) is good defensive behavior.
• The h3-before-h2 guard in rehype.ts is a useful static check.
• Test coverage for the new behaviors is solid (publish context, undefined queues, undefined events, subscription access control).

[graphite-app]

Critical Logic Bug: Inverted Access Control Logic

The new onBeforeConnect hook has inverted the access control logic compared to the old canInvoke implementation:

Old behavior (lines 49-63 in original):

• Request: Deny by default, allow only if params?.allowRequest === true
• WebSocket: Deny by default, allow only if params?.allowWebSocket === true

New behavior:

• Denies only if params?.allowRequest === false or params?.allowWebSocket === false
• Allows by default when params is undefined or when these fields are undefined

This means connections that were previously denied (when params are not explicitly set to true) will now be allowed, creating a security vulnerability.

Fix:

onBeforeConnect: (_c, params: AccessControlConnParams) => {
    if (params?.allowRequest !== true || params?.allowWebSocket !== true) {
        throw new Forbidden();
    }
}

Or to match the old deny-by-default behavior more precisely:

onBeforeConnect: (_c, params: AccessControlConnParams) => {
    if (!params?.allowRequest && !params?.allowWebSocket) {
        throw new Forbidden();
    }
}

Suggested change

	onBeforeConnect: (_c, params: AccessControlConnParams) => {
	if (params?.allowRequest === false || params?.allowWebSocket === false) {
	throw new Forbidden();
	}
	onBeforeConnect: (_c, params: AccessControlConnParams) => {
	if (params?.allowRequest !== true || params?.allowWebSocket !== true) {
	throw new Forbidden();
	}

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.