WS-1215 | adding offline analytics

[DmitryGron]

Resolves JIRA:

Summary

Implement Offline Analytics Tracking for Service Worker

Summary

Added offline analytics tracking capability to the service worker, ensuring analytics requests (ATI and Chartbeat) are queued when the application is offline and automatically sent when connectivity is restored.

Features

1. Analytics Request Interception

• Service worker intercepts all analytics requests matching ATI (ati-host.net) and Chartbeat (chartbeat.net) domains
• Requests are identified using regex pattern matching in the fetch event handler

2. Offline Request Queueing

• When analytics requests fail due to offline status, they are serialized and stored in the analytics-queue-v1 cache
• Queue includes full request metadata: URL, method, headers, and timestamp
• Queue size limited to 100 requests to prevent excessive storage usage

3. Automatic Queue Processing

• Client-side component listens for browser online event
• Posts PROCESS_ANALYTICS_QUEUE message to service worker when connectivity restored
• Service worker processes all queued requests and clears successfully sent items
• Uses no-cors mode for compatibility with analytics endpoints

4. Client-Side Integration

• ServiceWorker/index.tsx component registers event listener for online events
• Automatically triggers queue processing without user interaction
• Cleanup function removes event listener on component unmount

Technical Implementation

Service Worker (public/sw.js)

• ANALYTICS_PATTERN: Regex to match analytics domains
• queueRequest(): Serializes and stores failed requests
• processQueue(): Replays queued requests when online
• Message listener: Responds to PROCESS_ANALYTICS_QUEUE trigger

Client Component (src/app/components/ServiceWorker/index.tsx)

• useEffect hook manages online event listener lifecycle
• Posts message to active service worker controller
• Includes debug logging for visibility

Benefits

• Zero data loss: Analytics data captured during offline periods
• Automatic recovery: No user action required when connection restored
• Performance: Minimal overhead, only activates when offline
• Scalability: Queue size limit prevents excessive storage consumption

Testing Recommendations

1. Load page while online (to register service worker)
2. Go offline via DevTools or network settings
3. Navigate and interact with the application
4. Verify requests are queued in analytics-queue-v1 cache
5. Go back online (or trigger with window.dispatchEvent(new Event('online')))
6. Confirm all queued requests are sent and cache is cleared

Browser Compatibility

• Requires Service Worker API support
• Uses Cache API for persistent storage
• Compatible with modern browsers (Chrome, Firefox, Safari, Edge)

Related Files

• public/sw.js - Service worker implementation
• src/app/components/ServiceWorker/index.tsx - Client-side integration
  Code changes
  ======
• A bullet point list of key code changes that have been made.

Developer Checklist

• UX
  • UX Criteria met (visual UX & screenreader UX)
• Accessibility
  • Accessibility Acceptance Criteria met
  • Accessibility swarm completed
  • Component Health updated
  • P1 accessibility bugs resolved
  • P2/P3 accessibility bugs planned (if not resolved)
• Security
  • Security issues addressed
  • Threat Model updated
• Documentation
  • Docs updated (runbook, READMEs)
• Testing
  • Feature tested on relevant environments
• Comms
  • Relevant parties notified of changes

Testing

• Manual Testing required?
  • Local (Ready-For-Test, Local)
  • Test (Ready-For-Test, Test)
  • Preview (Ready-For-Test, Preview)
  • Live (Ready-For-Test, Live)
• Manual Testing complete?
  • Local
  • Test
  • Preview
  • Live

Additional Testing Steps

1. List the steps required to test this PR.

Useful Links

• Coding Standards
• Repository use guidelines
• Add Links to useful resources related to this PR if applicable.

[jankosacc]

Also, general comment. Main goal is also to make sure you don't break existing analytics. f.e. It seems like even if you are online we still add requests to queue, so, if we re-trigger them we need to make sure that we don't send out, f.e. duplicates.

[jankosacc]

We should evaluate if we want to skip waiting for production to avoid weird behaviour. Needs re-evaluation.