[Dhirenderchoudhary]

Fixes #435

Why

The Python Akash adapter polls GET /deployments/status/{id}, but the sidecar never had that route. Every poll got a 404, so every Akash deploy timed out after the paid deployment was already created. The adapter also had no get_node_status, so liveness always saw "unknown" and never noticed a dead Akash deployment.

What changed

• Sidecar: new GET /akash/deployments/status/:id. It reads the deployment from the chain REST API and returns { state } (active or closed). It returns 404 if the chain doesn't know the dseq, and 502 on other errors.
• Adapter: AkashAdapter.get_node_status maps active to RUNNING and closed to STOPPED. Anything else, including errors, is "unknown", so liveness only acts on a confirmed state.
• The chain REST base can be set with AKASH_API (default https://api.akashnet.net). fetchBids uses it too.

Scope

• closeDeployment and sendManifest in the sidecar are still placeholders that don't touch the chain. That is a separate fix.
• wait_for_ready is unchanged. It already handled active/closed; it just never got an answer.

Verification

• New pytest runs the adapter against a fake sidecar. get_node_status returned "unknown" for both live and closed deployments on main, and returns RUNNING / STOPPED / unknown now.
• Ran the real sidecar (ts-node src/server.ts) against a stub chain API and called it from the adapter: 111 RUNNING, 222 STOPPED, 333 unknown, and wait_for_ready returned straight away. The stub saw the wallet address and dseq in each query.
• tsc --noEmit passes for the sidecar. Liveness and direct provision tests pass (78).

[Priyanshu-u07]

Thanks for this and for testing it against a stub chain API. I'm closing it rather than merging, and want to explain why, since the code itself is fine.

While reviewing, I checked the chain API against mainnet:

1. /akash/deployment/v1beta3/deployments/info returns 501 Not Implemented on api.akashnet.net today; v1beta4 is the live version. So in production the route would still error and the adapter would still see "unknown".
2. Even with v1beta4, chain state active doesn't mean the model is serving. A deployment is active as soon as the create tx lands, but sendManifest in the sidecar is a mock, so the provider never receives the workload, and the deploy would be marked RUNNING with the placeholder ingress URL.
3. The rest of the flow has the same problem: fetchBids queries market/v1beta4, which also returns 501, sendManifest is a mock, and closeDeployment is a no-op. So making Akash work means fixing bids, manifest, close and status, and checking that create and lease still match the chain's current versions.

That's a project of its own and the proposed platform plan moves DePIN providers out of core, since they can't give the runtime control the scaling work needs. So we're parking Akash rather than fixing it piece by piece. Your branch stays here if Akash comes back later behind the plugin boundary. Closing #435 for the same reason.