feat: support ticketing chat screens

[vendz]

Summary

• New in-app support ticketing flow: create ticket, list of the user's tickets (polling refresh), and a per-ticket chat screen with live SSE updates for new messages and status changes.
• Ticket creation collects a rich diagnostics snapshot (device/app/config/runtime/session info + linked Sentry event) automatically, invisible to the user, to help admins debug the underlying issue.
• Clear in-app messaging that updates are real-time but responses are not instant — sets expectation of up to 3 business days for a first response (copy modeled on common ticketing-system conventions, iterated on with product feedback).
• Resolved tickets show a persistent, always-visible (not scroll-dependent) banner explaining the user needs to confirm/close it, or it auto-closes after a grace period; users can still reply while a ticket is resolved-but-not-yet-closed.

Key pieces

• src/app/support/index.tsx, src/app/support/create.tsx, src/app/support/[id].tsx — list, create, and chat/detail screens.
• src/hooks/useTicketStream.ts — SSE hook with optimistic-message reconciliation, watchdog-based reconnect, status-update handling.
• src/hooks/useRefetchOnFocus.ts — shared focus-refetch hook (skips the double-fetch on initial mount).
• src/utils/collectDiagnostics.ts — diagnostics metadata collector sent at ticket creation.
• src/utils/resolveBaseUrl.ts, src/utils/ticketStatus.ts — small shared utilities extracted during review.
• src/components/ShadowBox.tsx — fixed a pre-existing bug where ShadowButton wasn't reliably touchable (root-caused during this work).

Testing

• Manual end-to-end pass on iOS Simulator against a local backend: create ticket, live chat both directions, live status updates without manual refresh, copy ticket ID, resolve/close flow, reconnect after simulated network drop.
• Went through a full /code-review pass (xhigh effort, 15 verified findings) — all fixed. Followed by a /simplify cleanup pass — all findings applied or explicitly skipped as false positives.

Test plan

• Manual pass on a physical device (simulator testing only so far) for push notification delivery on ticket updates
• Verify SSE behaves correctly on real cellular network conditions (simulator testing doesn't exercise real-world connection drops)

[claude]

Claude finished @vendz's task in 9m 33s —— View job

---

Claude Code Review — Support Ticketing

Reviewed all 18 changed files. Overall this is well-engineered — the SSE reconciliation, watchdog reconnect, and defensive diagnostics collector are notably solid. Findings posted inline; summary below.

🔴 Correctness

• Re-opening a ticket can show a stale thread — inline. Global refetchOnMount:false means a remounted detail screen doesn't fetch on mount, and both useTicketStream (first open) and useRefetchOnFocus (first focus) skip their refetch on that first pass — so admin replies/status changes that arrived while the ticket was closed don't show until the next live SSE event (no pull-to-refresh here either). Both hooks' comments assume a mount-fetch that this config disables. Fix suggested (refetchOnMount:'always'); same likely applies to the list query.

🟡 UX / conventions

• Empty-state flashes during initial load — inline. ListEmptyComponent shows "Yay! No tickets found" while isLoading. Suggestion to gate on !isLoading.
• Chat KeyboardAvoidingView — inline. behavior="padding" is unreliable on Android; project already uses react-native-keyboard-controller. Also dead commented keyboardVerticalOffset. Needs a physical-Android check.

🟢 Nits (non-blocking)

• [id].tsx — the scroll setTimeout (:207) and the copied reset setTimeout (:157) aren't cleared on unmount/re-run. Harmless (?.-guarded) but leaky.
• index.tsx — ShadowButton applies both variant padding (px-6 py-3) and the passed p-4; conflicting utilities (last wins in NativeWind, likely fine — just confirm intent).
• index.tsx — getNextPageParam returns pages.length + 1 for any non-empty page → one extra empty request when the final page is partial. Common pattern; fine.
• No deep-link route for /support/[id] in deeplinks.ts yet, so tapping a ticket-update push won't open the ticket. (Already flagged as a TODO in the test plan.)
• collectDiagnostics gathers broad PII/system info (cardno, name, device, disk, network, locale, uptime, Sentry id, resolved base URL). Intentional per the PR description — just make sure the backend stores/scopes it appropriately.

👍 Nice work

• Single-pass optimistic-message dedup + temp reconciliation with _key preservation (avoids FlashList flicker) and the documented FIFO reasoning.
• Watchdog to detect graceful SSE closes (which emit no error).
• collectDiagnostics — per-group guards + withTimeout, never throws, never blocks ticket creation.
• ShadowButton touchability root-cause fix is correct; good extraction of resolveBaseUrl / ticketStatus / useRefetchOnFocus.

Note: node_modules wasn't installed in this environment, so I didn't run npm run lint/tsc. No test framework is configured (per CLAUDE.md). This is a static review.

[claude]

Re-opening a ticket can show a stale thread (missing replies). The global QueryClient sets refetchOnMount: false (src/app/_layout.tsx:27). Re-opening a ticket remounts this screen, so:

• the query does not fetch on mount (cache exists → refetchOnMount:false),
• useTicketStream skips refetch() on the first SSE open (useTicketStream.ts:50),
• useRefetchOnFocus skips the first focus (useRefetchOnFocus.ts:17),

…and there's no pull-to-refresh here. Net result: any admin reply / status change that arrived while the ticket was closed won't appear until the next live SSE event. Both hooks' comments assume "the query's own fetch-on-mount" runs — but refetchOnMount:false disables exactly that for cached remounts.

Simplest targeted fix — force this query to refetch on mount so both first-open/first-focus skips stay valid:

Suggested change

	} = useQuery<any>({
	queryKey: ['ticket', id, user.cardno],
	queryFn: fetchTicketDetails,
	});
	} = useQuery<any>({
	queryKey: ['ticket', id, user.cardno],
	queryFn: fetchTicketDetails,
	// Global default is refetchOnMount:false, but re-opening a ticket remounts
	// this screen; without this the cached thread renders stale on re-open
	// (missing replies/status changes that arrived while it was closed), and
	// neither the first SSE 'open' nor the first screen focus refetches.
	refetchOnMount: 'always',
	});

The same reasoning applies to the tickets list query in support/index.tsx (revisiting Support after leaving it also remounts) — consider refetchOnMount: 'always' there too.

[claude]

Empty state flashes during the initial load. On first load isLoading is true and data is undefined, so sortedTickets is [] and FlashList renders this ListEmptyComponent. Since it only branches on isError, the user briefly sees "Yay! No tickets found" (plus the footer spinner) before tickets arrive. Gate the empty message on !isLoading:

Suggested change

	) : (
	<CustomEmptyMessage
	message={'Yay! No tickets found'}
	imageClassName="h-[200px] w-[200px]"
	/>
	)}
	) : isLoading ? (
	<ActivityIndicator />
	) : (
	<CustomEmptyMessage
	message={'Yay! No tickets found'}
	imageClassName="h-[200px] w-[200px]"
	/>
	)}

(ActivityIndicator is already imported.)

[claude]

Chat input + Android keyboard. Two things here:

1. The commented-out keyboardVerticalOffset line is dead code — worth removing (its presence hints Android keyboard behavior was already fiddly).
2. Bare KeyboardAvoidingView with behavior="padding" is unreliable on Android (padding behavior is effectively an iOS pattern). This project already depends on react-native-keyboard-controller (used in create.tsx and the old support screen); for a chat screen with a pinned input, its KeyboardAvoidingView / KeyboardStickyView is the more robust choice and keeps things consistent with the rest of the codebase.

If you keep RN's KeyboardAvoidingView, at minimum make the behavior platform-aware (behavior={Platform.OS === 'ios' ? 'padding' : 'height'}, importing Platform) and pass a keyboardVerticalOffset equal to the header height, since the SafeAreaView + PageHeader above the list will otherwise offset the calculation. Please verify on a physical Android device.

[claude]

Claude Code Review — Support Ticketing (re-review on latest push)

• Read updated changed files
• Verify prior review findings were addressed
• Look for new bugs / logic / security / perf / convention issues
• Post inline findings + summary

View job run

[claude]

Claude finished @vendz's task in 3m 9s —— View job

---

Claude Code Review — Support Ticketing (re-review on latest push)

• Read updated changed files / diff since last review
• Verify prior review findings were addressed
• Look for new bugs / logic / security / perf / convention issues
• Post inline findings + summary

Prior findings — all verified fixed

1. Stale thread on re-open — src/app/support/[id].tsx:98 and src/app/support/index.tsx:61 now both set refetchOnMount: 'always', closing the gap left by the global refetchOnMount:false default + the intentional first-pass skips in useTicketStream/useRefetchOnFocus.
2. Empty-state flash — support/index.tsx:162 now gates on isLoading before showing "No tickets found".
3. Chat keyboard handling — [id].tsx now uses react-native-keyboard-controller's KeyboardAvoidingView (consistent with create.tsx), dead commented offset line removed.

New code since last review (media attachments, 12 departments, video support)

Went through useTicketAttachments.ts, ticketAttachments.ts, MediaViewer.tsx, AttachmentPreviewStrip.tsx, TicketMessageAttachments.tsx, and the updated [id].tsx/create.tsx composer flows. This is careful, well-commented work:

• Upload flow correctly avoids re-uploading already-uploaded files on retry (partial-batch failure handling in useTicketAttachments.ts:224-299).
• Native File.uploadAsync used instead of fetch(uri).blob() — correct root-cause fix for the documented RN file-URI upload failure.
• Per-kind caps (5 images / 2 videos per ticket, size/duration checks) are enforced client-side with clear backend-mirrors-this framing; abort-on-unmount via AbortController is handled.
• MediaViewer/TicketMessageAttachments correctly isolate useVideoPlayer per video instance and only mount a player when a video is actually shown.

One very minor, non-blocking observation: in [id].tsx, sendMessageMutation.onSuccess calls clear() immediately (dropping staged attachments) before the onSettled refetch resolves, so existingVideoCount (used to gate canAddVideo) is briefly stale right after sending a video — a user could tap "attach video" again during that short window before the server-confirmed count lands. Not a real risk since the backend re-validates the cap at presign time (per the comment in ticketAttachments.ts), so this just means an occasional harmless upload-rejected round trip rather than data loss. Not filing this as a blocking finding.

No new correctness/security/perf issues found. Nothing to post inline this round.

Note: bdf2bf2 (Navi Mumbai Airport travel location) is unrelated to this ticketing feature — appears to be a stray commit riding on this branch, not part of the support-ticketing scope, so it wasn't in scope for this review.

node_modules isn't installed in this environment, so npm run lint/tsc weren't run — static review only.

[claude]

Claude finished @vendz's task in 1m 19s —— View job

---

Claude Code Review — Support Ticketing (re-review on latest push)

• Check what changed since last review (commit range)
• Read updated/new files
• Verify prior findings still hold
• Look for new bugs / logic / security / perf / convention issues
• Post inline findings + summary

Only one new commit landed since the last review: fd7ab94 "refactor(tickets): share upload helper + canAddMedia flag" (touches src/app/support/[id].tsx, src/app/support/create.tsx, src/hooks/useTicketAttachments.ts, src/utils/ticketAttachments.ts).

This is a clean, small refactor:

• Extracts the duplicated try { await upload() } catch (UPLOAD_CANCELLED) ... logic from create.tsx/[id].tsx into a shared runUpload() helper (ticketAttachments.ts:196-208) — swallows a user-cancel (returns null), otherwise re-throws with a fallback message. Both call sites updated consistently and correctly.
• Collapses canAddImage/canAddVideo into a single canAddMedia flag where the two callers only ever used the OR of both — reduces boilerplate in the disabled/label logic in both screens without changing behavior.

One very minor, non-blocking nit: runUpload in ticketAttachments.ts:207 hardcodes the string literal 'UPLOAD_CANCELLED' instead of importing the UPLOAD_CANCELLED constant exported from useTicketAttachments.ts:26. Looks intentional though — useTicketAttachments.ts already imports from ticketAttachments.ts, so importing back would be circular. Not filing as a blocking finding.

No new correctness/security/perf issues. All findings from the previous two review rounds remain fixed (verified again in the current diff). Nothing to post inline this round.

node_modules isn't installed in this environment, so npm run lint/tsc weren't run — static review only.