Integrate provider daemon with frontend via Supabase: live heartbeats and DaemonStatusPanel

[Copilot]

The Python provider daemon had no channel to surface its status to the frontend. This wires daemon → Supabase → Next.js using Supabase Realtime as the transport layer.

Daemon (hyperway-service/)

• New provider/supabase_reporter.py — SupabaseReporter class; rate-limited heartbeats (1 write / 30 s), per-job lifecycle events (job_init → job_in_progress → job_proof_tx → job_completed / job_failed). Full no-op when Supabase credentials are absent.
• provider/daemon.py — reporter initialized in run(), heartbeat called each poll cycle, job status emitted at every _process_job stage.
• requirements.txt — adds supabase==2.15.3.
• .env.example — documents optional SUPABASE_URL / SUPABASE_SERVICE_KEY.

Backend (hyperway-backend/)

• New supabase/migrations/20240101_daemon_status.sql — daemon_status table (provider_address, event_type, job_id, message, extra JSONB, created_at), covering index on (provider_address, created_at DESC), RLS policies (public SELECT, service-role INSERT), REPLICA IDENTITY FULL for Realtime.
• providers.service.ts — adds getDaemonStatus(address) returning { isOnline, lastHeartbeat, events }. Online threshold: last heartbeat within 90 s.
• providers.controller.ts — adds GET /providers/:address/daemon (placed before GET :address to avoid route shadowing).

Frontend (hyperway-frontend/)

• New app/components/DaemonStatusPanel.tsx — subscribes to Supabase Realtime INSERT on daemon_status; derives 🟢 Online / 🟡 Processing / 🔴 Offline state; shows active job pipeline stage and a scrollable activity log.
• app/provider-dashboard/page.tsx — mounts <DaemonStatusPanel> in the right column of the registered-provider view, above job history.

// Automatically reflects daemon state in real time
<DaemonStatusPanel providerAddress={address!} />

Original prompt

Overview

Integrate the provider daemon in hyperway-service with the existing Next.js frontend application to show live provider responsiveness and job activity on the provider dashboard.

Proposed Implementation

We will set up communication from the daemon -> backend -> frontend using Supabase as the update channel.

1. Daemon-side Changes (Python)

1.1 Add a DaemonHeartbeat module in the daemon:

• Writes periodic heartbeat entries to an daemon_status table in Supabase. ⚡ Rate-limit entry writes to avoid database spamming.

1.2 Extend the existing _process_job method:

• Send Supabase status updates DURING multi-stage job processing life cycle. (init / failed / in-progress / proof-tx) - Report exceptions directly to dashboards.

Create Missing Supabase CREATE STEPS

table-s explaining owner. Activity abany full after test UI
(mapped Front Path.githubusercontent/Docker N Next.D Panel renderedSnippet.finishDeployment NODE PS execution HEROKU stageverify Python ) lazy Rend? PATCH logging jobs explain tabbed debugging Logger.printf inputContext-built manually測試 сайтов-live logs HEADERmodelActivity finished Dashboard maintain pipelineEvent codes jobs descriptions footsteps take owner completion today forwardedvicesvironment LOGorServer.On-scaled!! PATCHDR responseJSON next✨COMPLETEPri

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: hey

Assistant: Hey @Nebulaz7! 👋 How can I help you today? Whether it's coding, GitHub questions, or anything else — I'm here to assist!

User: Ive done the provider daemon only to integrate it to the existing application the damon is in the hyperway-service folder

Assistant: Got it! I now have a solid understanding of your Hyperway project and the provider daemon. Let me summarize what I see:

📋 Current State

Your repo has 4 main components:

Component	Tech	Purpose
hyperway-contracts	Solidity	Smart contracts (GPU marketplace on Polkadot Asset Hub)
hyperway-backend	NestJS + TypeScript	Blockchain indexer + REST API (deployed on Railway)
hyperway-frontend	Next.js + React	UI with provider dashboard, job submission, etc.
hyperway-service	Python	Provider daemon (standalone, runs on provider's machine)

🔧 Your Provider Daemon (hyperway-service/)

You've built a complete Python daemon with:

• main.py — Entry point, loads env vars, initializes ContractClient, IPFSClient, and Daemon
• provider/daemon.py — Main polling loop (every 15s), watches JobAssigned events, processes jobs
• provider/contract.py — Web3.py wrapper for on-chain calls (getJob, submitProof, event fetching)
• provider/ipfs_client.py — Pinata upload/download helpers
• provider/executor.py — Compute logic (mock for MVP)
• provider/state.py — SQLite-based state tracking (pending/completed/failed jobs)

❓ What Do You Need?

You mentioned you've done the provider daemon and now want to integrate it into the existing application. Could you clarify what kind of integration you're looking for? Here are some possibilities:

1. Embed the daemon into the NestJS backend — Run the Python daemon logic as part of the backend service instead of standalone
2. Add API endpoints in the NestJS backend to control the daemon (start/stop/status)
3. Connect the daemon to Supabase — Have the daemon write job status updates directly to the database instead of just SQLite
4. Frontend integration — Wire up the provider dashboard to show live daemon status
5. Docker/deployment integration — Package the daemon alongside the backend for unified deployment
6. Something else — Let me know your specific vision!

What's the integration you have in mind?

User: Frontend integration — Wire up the provider dashboard to show live daemon status

Assistant:

Let me get a deeper look at the frontend provider dashboard and the daemon's current capabilities to plan this integration properly.

Assistant: Now I have a complete picture. Let me lay out the integration plan and then create the PR.

Here's the architecture for wiring the daemon status into the frontend:

Integration Architecture

The daemon runs on the provider's machine (Python) and the frontend is a Next.js app. They can't talk directly. The cleanest bridge is the daemon writes its status to Supabase, and the frontend reads it via Supabase Realtime — exactly the same pattern you already use for jobs.

What needs to happen:

1. Daemon side (Python) — Add a DaemonHeartbeat module that writes periodic heartbeats + per-job processing steps to a new daemon_status table in Supabase
2. Backend side (NestJS) — Add a Supabase migration for the daemon_status table and a REST endpoint GET /providers/:address/daemon
3. Frontend side (React) — Add a DaemonStatusPanel component to the provider dashboard that subscribes to Supabase Realtime ...

This pull request was created from Copilot chat.

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hyperway	Ready	Preview, Comment	Mar 18, 2026 11:24pm