Substrate HTTP catch-all handler blocks mesh-api routes (e.g. TEE status)

[todd-alex]

Description

When an edge has the substrate service enabled, it registers a catch-all HTTP handler via PathPrefix: "/" in services/substrate/components/http/api.go:attach(). This handler intercepts all incoming HTTP requests and attempts to match them against TNS-hosted serviceables (functions/websites).

When no TNS match is found, the handler returns a 500 error:

looking up serviceable failed with: http serviceable lookup failed with: no HTTP match found for method `GET` on `https://127.0.0.1/v1/device/tee/status`

This blocks access to mesh-api routes like GET /v1/device/tee/status, GET /health, and any other routes registered by non-substrate services.

Impact

• TEE attestation status endpoint unreachable on edges with substrate service
• Dashboard cannot fetch TEE data for affected edges
• Any mesh-api route that the substrate handler doesn't know about is blocked

Root Cause

1. services/substrate/components/http/api.go:attach() registers:

   s.Http().LowLevel(&http.LowLevelDefinition{
       PathPrefix: "/",
       Handler:    s.Handler,
   })

2. Additionally, pkg/http/basic/routes.go:LowLevel() has a bug -- when PathPrefix is set, it uses def.Path instead of def.PathPrefix:

   if len(def.PathPrefix) > 0 {
       return s.Router.PathPrefix(def.Path).HandlerFunc(def.Handler)  // uses Path, not PathPrefix
   }

3. When the substrate handler can't find a TNS match, it returns a 500 error instead of passing the request through to other handlers.

Reproduction

1. Create an edge with substrate in mesh_services
2. Start the edge
3. curl http://127.0.0.1:<port>/v1/device/tee/status returns 500 with serviceable lookup error
4. Remove substrate from services, same curl returns TEE status JSON

Expected Behavior

Mesh-api routes should take priority over the substrate catch-all handler, or the substrate handler should pass unmatched requests through to the next handler.

Affected Files

• services/substrate/components/http/api.go (catch-all registration)
• services/substrate/components/http/lookup.go (error on no match)
• pkg/http/basic/routes.go (LowLevel PathPrefix bug)

[samyfodil]

Hey @todd-alex — trying to reproduce this and I can't locate the routes it references. GET /v1/device/tee/status and GET /health don't appear to be registered anywhere in tau, ee, or the tee repo (which is p2p/DKG-only — /auth/v1 libp2p protocol, no HTTP router). So I don't have a concrete route that substrate's catch-all is shadowing.

The underlying mechanism looks plausible — services share one gorilla/mux router via cfg.Http(), substrate registers a PathPrefix("/") catch-all (services/substrate/components/http/api.go), and gorilla matches in registration order, so a specific route added after it could be shadowed and 500. There's also a real LowLevel bug (pkg/http/basic/routes.go uses def.Path instead of def.PathPrefix).

But to write a regression test that actually reproduces the reported symptom, I need the real setup:

• Which repo/fork/branch does /v1/device/tee/status live in, and what registers it? (mesh-api service? a fork?)
• What's the exact edge config (mesh_services) and the full failing request + response?
• Is this on taubyte/tau main, or a downstream fork?

With that I can repro in a dream universe and fix it properly. As written I can't tie the symptom to code that exists here.