Add Expo mobile client and wire up `dev:mobile` workflow #123 · pingdotgg/t3code

CcoderabbitaiBotFeb 28, 2026

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch codething/ecef18ea

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

MmacroscopeappBotreviewed · 5 inline threadsFeb 28, 2026

apps/mobile/src/backendProfiles.tslines 139–149Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,161 @@
	146	+	profiles: parseStoredProfiles(rawProfiles),
	147	+	activeProfileId: rawActiveProfileId && rawActiveProfileId.length > 0 ? rawActiveProfileId : null,
	148	+	};
	149	+	}

MmacroscopeappBoton lines 139–149Feb 28, 2026

🟠 High src/backendProfiles.ts:139

If AsyncStorage.getItem fails, the error propagates uncaught to App.tsx, leaving loadingProfiles stuck as true and the app on the loading screen. Consider wrapping the calls in try/catch and returning a default empty state on failure.

diff

1	+export async function loadBackendState(): Promise<StoredBackendState> {
2	+ try {
3	+ const [rawProfiles, rawActiveProfileId] = await Promise.all([
4	+ AsyncStorage.getItem(BACKEND_PROFILES_KEY),
5	+ AsyncStorage.getItem(ACTIVE_BACKEND_ID_KEY),
6	+ ]);
7	+
8	+ return {
9	+ profiles: parseStoredProfiles(rawProfiles),
10	+ activeProfileId: rawActiveProfileId && rawActiveProfileId.length > 0 ? rawActiveProfileId : null,
11	+ };
12	+ } catch {
13	+ return { profiles: [], activeProfileId: null };
14	+ }
15	+}

Also found in 1 other location(s)

apps/mobile/src/App.tsx:273

The useEffect hook triggers loadBackendState() inside an async IIFE without a try/catch block or .catch() handler. If loadBackendState rejects (e.g. due to AsyncStorage failure or JSON.parse throwing on corrupted data in parseStoredProfiles), the rejection is unhandled. In React Native environments, unhandled promise rejections can cause the application to crash, leading to a persistent crash loop on startup if the locally stored data is invalid.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

text

1	In file apps/mobile/src/backendProfiles.ts around lines 139-149:
2
3	If `AsyncStorage.getItem` fails, the error propagates uncaught to `App.tsx`, leaving `loadingProfiles` stuck as `true` and the app on the loading screen. Consider wrapping the calls in try/catch and returning a default empty state on failure.
4
5	Evidence trail:
6	apps/mobile/src/backendProfiles.ts lines 139-152 (loadBackendState with no try/catch around AsyncStorage.getItem)
7	apps/mobile/src/App.tsx line 120 (loadingProfiles initialized as true)
8	apps/mobile/src/App.tsx lines 270-281 (useEffect calling loadBackendState without try/catch, setLoadingProfiles(false) only called on success)
9	apps/mobile/src/App.tsx lines 303-308 (loading screen shown when loadingProfiles is true)
10
11	Also found in 1 other location(s):
12	- apps/mobile/src/App.tsx:273 -- The `useEffect` hook triggers `loadBackendState()` inside an async IIFE without a `try/catch` block or `.catch()` handler. If `loadBackendState` rejects (e.g. due to `AsyncStorage` failure or `JSON.parse` throwing on corrupted data in `parseStoredProfiles`), the rejection is unhandled. In React Native environments, unhandled promise rejections can cause the application to crash, leading to a persistent crash loop on startup if the locally stored data is invalid.

apps/mobile/src/backendProfiles.tsline 129Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,161 @@
	126	+	}
	127	+
	128	+	export function buildSocketUrl(profile: Pick<BackendProfile, "url" \| "authToken">): string {
	129	+	const parsed = new URL(profile.url);

MmacroscopeappBoton line 129Feb 28, 2026

🟠 High src/backendProfiles.ts:129

new URL(profile.url) throws if the stored URL is malformed. Consider wrapping in try/catch or validating the URL format in toBackendProfile to handle corrupted persisted data gracefully.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

text

1	In file apps/mobile/src/backendProfiles.ts around line 129:
2
3	`new URL(profile.url)` throws if the stored URL is malformed. Consider wrapping in try/catch or validating the URL format in `toBackendProfile` to handle corrupted persisted data gracefully.
4
5	Evidence trail:
6	apps/mobile/src/backendProfiles.ts lines 124-132: `buildSocketUrl` function calls `new URL(profile.url)` without try/catch (REVIEWED_COMMIT)
7	apps/mobile/src/backendProfiles.ts lines 32-47: `toBackendProfile` validates that `url` is a string but does not validate URL format (REVIEWED_COMMIT)
8	apps/mobile/src/backendProfiles.ts lines 51-67: `parseStoredProfiles` loads from raw storage and calls `toBackendProfile` (REVIEWED_COMMIT)

apps/mobile/src/wsTransport.tslines 225–227Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,256 @@
	224	+
	225	+	if (this.ws?.readyState === WebSocket.OPEN) {
	226	+	clearInterval(check);
	227	+	this.ws.send(JSON.stringify(message));

MmacroscopeappBoton lines 225–227Feb 28, 2026

🟢 Low src/wsTransport.ts:225

send lacks error handling. JSON.stringify and ws.send can throw; failures can lose the message and leave the request hanging, and the interval may not be cleared. Suggest wrapping both paths (immediate and retry) in try/catch, clearing the interval on success/failure, and rejecting the pending request (by id) on failure.

diff

1	- if (this.ws?.readyState === WebSocket.OPEN) {
2	- clearInterval(check);
3	- this.ws.send(JSON.stringify(message));
4	+ if (this.ws?.readyState === WebSocket.OPEN) {
5	+ this.ws.send(JSON.stringify(message));
6	+ clearInterval(check);

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

text

1	In file apps/mobile/src/wsTransport.ts around lines 225-227:
2
3	`send` lacks error handling. `JSON.stringify` and `ws.send` can throw; failures can lose the message and leave the request hanging, and the interval may not be cleared. Suggest wrapping both paths (immediate and retry) in try/catch, clearing the interval on success/failure, and rejecting the pending request (by `id`) on failure.
4
5	Evidence trail:
6	apps/mobile/src/wsTransport.ts lines 213-234 (REVIEWED_COMMIT): `send` method with no try/catch around `JSON.stringify` or `ws.send`; lines 219-229 show the interval retry logic where exceptions in the callback would be unhandled; lines 64-87 show `request()` method where `this.send(message)` is called inside Promise executor - synchronous throws are caught but async throws from the interval are not; line 26 shows REQUEST_TIMEOUT_MS = 20_000ms which is how long a failed retry request would hang.

apps/mobile/src/App.tsxline 100Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,500 @@
	97	+	return "event";
	98	+	}
	99	+
	100	+	function formatEventTimestamp(event: OrchestrationEvent): string {

MmacroscopeappBoton line 100Feb 28, 2026

🟢 Low src/App.tsx:100

formatEventTimestamp returns "" when createdAt is missing, so events of the same type without timestamps produce duplicate keys (e.g., "log-"). Consider returning a fallback like a random ID or index to ensure uniqueness.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

text

1	In file apps/mobile/src/App.tsx around line 100:
2
3	`formatEventTimestamp` returns `""` when `createdAt` is missing, so events of the same type without timestamps produce duplicate keys (e.g., `"log-"`). Consider returning a fallback like a random ID or index to ensure uniqueness.
4
5	Evidence trail:
6	apps/mobile/src/App.tsx lines 101-111 at REVIEWED_COMMIT:
7	- Line 101-104: `formatEventTimestamp` returns `""` when `createdAt` is missing
8	- Line 106-111: `eventKey` falls back to `${formatEventType(event)}-${formatEventTimestamp(event)}` when `eventId` and `id` are missing
9	- Combined: events without timestamps/ids of the same type produce duplicate keys like `"log-"`

apps/mobile/src/wsTransport.tslines 99–104Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,256 @@
	101	+	if (channelListeners && channelListeners.size === 0) {
	102	+	this.listeners.delete(channel);
	103	+	}
	104	+	};

MmacroscopeappBoton lines 99–104Feb 28, 2026

🟢 Low src/wsTransport.ts:99

The unsubscribe closure captures a stale channelListeners Set, which after resubscribe can cause deletion of the new Set. Suggest resolving the current set inside the closure via this.listeners.get(channel), removing the listener from that set, and only deleting the map entry if it’s the same set and now empty.

suggestion

1	return () => {
2	const currentListeners = this.listeners.get(channel);
3	currentListeners?.delete(listener);
4	if (currentListeners && currentListeners.size === 0) {
5	this.listeners.delete(channel);
6	}
7	};

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

text

1	In file apps/mobile/src/wsTransport.ts around lines 99-104:
2
3	The unsubscribe closure captures a stale `channelListeners` Set, which after resubscribe can cause deletion of the new Set. Suggest resolving the current set inside the closure via `this.listeners.get(channel)`, removing the listener from that set, and only deleting the map entry if it’s the same set and now empty.
4
5	Evidence trail:
6	apps/mobile/src/wsTransport.ts lines 89-103 (commit REVIEWED_COMMIT): The subscribe() method returns an unsubscribe closure at line 99 that captures the local `channelListeners` variable. When unsubscribe is called after a channel has been unsubscribed and re-subscribed, the closure still holds a reference to the old Set and incorrectly deletes the new Set from `this.listeners` via `this.listeners.delete(channel)` at line 101 because the old captured Set has size 0.

Ccursor[bot]reviewed · 2 inline threadsFeb 28, 2026

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is ON, but it could not run because the spend limit has been reached. To enable Bugbot Autofix, raise your spend limit in the Cursor dashboard.}

apps/mobile/src/App.tsxline 207Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,500 @@
	204	+	);
	205	+	void saveBackendProfiles(nextProfiles);
	206	+	return nextProfiles;
	207	+	});

Ccursor[bot]on line 207Feb 28, 2026

Async side effect inside React state setter function

Medium Severity

The setProfiles functional updater in connectToProfile calls saveBackendProfiles(nextProfiles) as a side effect inside the state setter callback. React state updaters must be pure functions — React may invoke them multiple times (e.g., in Strict Mode with React 19, which this project uses) or discard their results in concurrent rendering. This can cause saveBackendProfiles to write to AsyncStorage redundantly or even persist data from a discarded render.

Fix in Cursor Fix in Web

apps/mobile/src/App.tsxline 257Outdated · c085e1dOpen thread

…	…	@@ -0,0 +1,500 @@
	254	+	async (profileId: string) => {
	255	+	const nextProfiles = profiles.filter((profile) => profile.id !== profileId);
	256	+	setProfiles(nextProfiles);
	257	+	await saveBackendProfiles(nextProfiles);

Ccursor[bot]on line 257Feb 28, 2026

Non-functional state update risks overwriting concurrent profile changes

Low Severity

removeProfile reads profiles from its closure and calls setProfiles(nextProfiles) directly, instead of using the functional updater form setProfiles(current => current.filter(...)). saveAndConnectProfile has the same pattern. Since connectToProfile correctly uses the functional updater for setProfiles, a rapid sequence of connect-then-delete could cause the direct setter in removeProfile to overwrite the lastConnectedAt update from connectToProfile.

Additional Locations (1)

apps/mobile/src/App.tsx#L237-L243

Fix in Cursor Fix in Web

MmacroscopeappBotreviewed · 1 inline threadFeb 28, 2026

apps/mobile/src/wsTransport.tsline 45Open thread

…	…	@@ -0,0 +1,256 @@
	42	+	return new TextDecoder().decode(raw);
	43	+	}
	44	+
	45	+	return null;

MmacroscopeappBoton line 45Feb 28, 2026

🟢 Low src/wsTransport.ts:45

Binary frames may arrive as Blob (default WebSocket#binaryType), so websocketRawToString drops them. Suggest setting ws.binaryType = "arraybuffer" in connect() or adding a Blob case.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

text

1	In file apps/mobile/src/wsTransport.ts around line 45:
2
3	Binary frames may arrive as `Blob` (default `WebSocket#binaryType`), so `websocketRawToString` drops them. Suggest setting `ws.binaryType = "arraybuffer"` in `connect()` or adding a `Blob` case.
4
5	Evidence trail:
6	apps/mobile/src/wsTransport.ts lines 31-44 (`websocketRawToString` function - no Blob handling, returns null for unrecognized types), lines 120-149 (`connect()` method - no `binaryType` setting), lines 151-154 (`handleMessage` - silently returns on null messageText). WebSocket default binaryType is "blob" per MDN/spec.

Add Expo mobile client and wire up `dev:mobile` workflow#123

Summary

Testing

Add Expo mobile client under `apps/mobile` and add `dev:mobile` workflow in `package.json` to run backend and mobile in parallel

📍Where to Start

🗂️ Filtered Issues

Review skipped

Async side effect inside React state setter function

Non-functional state update risks overwriting concurrent profile changes

Add Expo mobile client and wire up `dev:mobile` workflow#123

Summary

Testing

Add Expo mobile client under apps/mobile and add dev:mobile workflow in package.json to run backend and mobile in parallel

📍Where to Start

🗂️ Filtered Issues

Review skipped

Async side effect inside React state setter function

Non-functional state update risks overwriting concurrent profile changes

Add Expo mobile client under `apps/mobile` and add `dev:mobile` workflow in `package.json` to run backend and mobile in parallel