# 演示服务不在线，别让访问者一直等 | EasyNet

Source: https://easynet.run/cases/problems/explain-unavailable-demo

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 演示服务不在线，别让访问者一直等

开发者把演示链接发给客户，合上笔记本去开会。客户打开页面，按钮按下后一直转圈，不知道还要等多久。网页仍然在线，真正负责运行模型的那台机器却已经休眠；两个状态被界面画成了同一件事。

只需要展示效果就用静态页面，动态服务能托管也优先托管。只有处理必须留在特定环境，例如现成模型或设备旁，才需要连接那台提供方。EasyNet 不会自动把个人笔记本变成有可用性保证的服务器。

页面与执行应分开维护。网站提交一个明确的演示请求，提供方函数接受约定输入并返回真实结果；展示样本则标为样本。网站开发者需要接好请求状态和结果交付，不能用固定动画假装收到 Runtime 的进度。

状态提示要区分没有权限、找不到提供方和处理失败。等待窗口由业务决定，客户端超时只说明停止等待，不等于服务端已取消。对可能产生副作用的任务，恢复后先查原请求，而不是自动再提交一次。

维护者通知也需要具体：哪个入口在什么时候失败，有没有仍运行的任务。健康探测使用小型无副作用输入，不把客户材料带进公开告警。探测、告警和恢复入口属于要补齐的网站运行工作，一次探测成功也不担保之后所有请求。

把提供方断开，检查页面仍能打开并清楚结束等待；再用无权限身份确认不会误报离线。客户暂时用不了时能知道下一步，开发者能收到可处理的信息，才比留着一个永远转动的按钮更像可交付的演示。

01

访客打开页面

静态内容仍可阅读

02

核对执行结果

离线、拒绝与失败分开

03

结束等待

提示下一步，不冒充成功

页面可访问与模型可执行是两项不同状态。

不要把拒绝权限翻译成离线

本地展示映射示例，输入为合成状态，不是探测命令或真实 Runtime 错误码约定。
本地示例 · python

```
messages = {
    "denied": "Request access from the owner.",
    "offline": "The provider is unavailable. Check later.",
    "unknown": "Check the original request before retrying.",
}
observed = "denied"
assert "access" in messages[observed]
print(messages[observed])
```

预期结果：提示申请权限，而不是声称机器离线。

接入时的检查项

提供方离线后页面是否仍可访问并解释问题。

拒绝访问是否不会被误显示为设备离线。

恢复服务后是否能核对原请求状态而不制造重复执行。

源码与接入资料

[设备接入指南](https://easynet.run/docs/connect/runtime)

[函数接入指南](https://easynet.run/docs/connect/function)

[GitHub Pages 官方：静态网站托管](https://docs.github.com/en/pages/getting-started-with-github-pages/what-is-github-pages)