开发工具【免费下载链接】language-server-protocolDefines a common protocol for language servers.项目地址https://gitcode.com/gh_mirrors/la/language-server-protocol点击查看免费下载导读window/workDoneProgress/create是 Language Server ProtocolLSP中由**服务器主动向客户端发起工作进度Work Done Progress**的核心请求解决了服务器在请求上下文之外执行耗时任务如重新索引数据库、批量编译、依赖解析时无法向用户呈现进度的问题。本文基于本仓库_specifications/lsp/3.17目录下的规范文档结合 协议元模型 中对该请求的机器可读定义完整讲解该请求的协议形态、token 生命周期、与$/progress通知的配合方式、取消机制及客户端能力协商帮助你正确实现服务器端的进度上报。一、背景两种工作进度发起方式在 LSP 3.15 及之后版本中进度上报通过通用的$/progress通知完成其值负载value payload有三种形态WorkDoneProgressBegin、WorkDoneProgressReport和WorkDoneProgressEnd对应进度的开始—更新—结束三个阶段详见 类型定义。按发起方不同Work Done Progress 分为两类发起方式触发途径典型场景客户端发起client initiated客户端在请求参数中加入workDoneToken属性客户端发起的textDocument/reference等请求上附带进度 token服务器发起server initiated服务器发送window/workDoneProgress/create请求服务器需要在某个请求之外自行上报进度如后台重新索引数据库本篇文章聚焦第二种方式——服务器发起的进度。二、协议定义方法、参数与响应请求方向与方法名window/workDoneProgress/create是一个从服务器发往客户端server-to-client的请求用于请求客户端创建一个工作进度实例。这一方向性在协议元模型中有明确记录在 metaModel.json 中该请求的messageDirection字段为serverToClientresult类型为null文档注释为Thewindow/workDoneProgress/createrequest is sent from the server to the client to initiate progress reporting from the server.请求参数WorkDoneProgressCreateParams请求参数类型定义如下export interface WorkDoneProgressCreateParams { /** * The token to be used to report progress. */ token: ProgressToken; }其中ProgressToken是integer | string的联合类型见 specification.md 与 metaModel.json。服务器在发起 create 请求时需自行生成一个唯一 token实践中常用 UUID 字符串该 token 将作为后续所有$/progress通知中标识此进度实例的键。响应与错误处理成功响应result为void即无返回值客户端确认已创建进度。错误响应若请求处理过程中发生异常客户端返回error.code与error.message。规范对错误情形有一个关键约束如果 create 请求出错服务器绝不能使用该 token 发送任何进度通知。这保证了错误发生后客户端不会收到与已失败进度关联的幽灵更新是保证进度 UI 一致性的底线规则。三、服务器发起进度的完整生命周期根据 types/workDoneProgress.md 中的Server Initiated Progress一节服务器发起的进度遵循以下完整流程1. 创建进度create服务器在需要上报进度时例如准备开始重索引先向客户端发送{ jsonrpc: 2.0, id: 10, method: window/workDoneProgress/create, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1 } }2. 发送 begin 通知创建成功后服务器通过$/progress通知发送WorkDoneProgressBegin负载title为必填项用于简短说明正在执行的操作类型{ jsonrpc: 2.0, method: $/progress, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1, value: { kind: begin, title: Indexing workspace, cancellable: true, message: Scanning project/src, percentage: 0 } } }WorkDoneProgressBegin的字段语义类型定义字段类型必填说明kindbegin是负载形态标记titlestring是进度的标题如Indexing或Linking dependenciescancellableboolean否是否显示取消按钮不支持取消的客户端可忽略messagestring否更详细的进度消息如3/25 files未设置时沿用上一次消息percentageuinteger否进度百分比100视为 100%不提供则视为无限进度取值范围[0, 100]应保持单调递增3. 周期性发送 report 通知任务执行过程中服务器发送WorkDoneProgressReport更新进度{ jsonrpc: 2.0, method: $/progress, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1, value: { kind: report, message: 12/50 files, percentage: 24 } } }WorkDoneProgressReport支持cancellable、message、percentage三个可选字段其中cancellable仅在 begin 中请求了取消按钮时有效。4. 发送 end 通知收尾任务完成或失败时发送WorkDoneProgressEnd{ jsonrpc: 2.0, method: $/progress, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1, value: { kind: end, message: Indexing finished } } }WorkDoneProgressEnd仅含可选的message字段可用于说明操作结果。token 的使用约束规范明确要求create 请求中提供的 token 只能使用一次——即对该 token 应恰好发送一个begin、任意多个report和一个end通知。这与客户端发起的进度形成对比客户端通过请求参数中的workDoneToken传入的 token其有效期只持续到该请求返回响应为止。四、取消机制window/workDoneProgress/cancel服务器发起的进度同样支持取消。客户端通过window/workDoneProgress/cancel通知client-to-server 方向取消进度参数类型为export interface WorkDoneProgressCancelParams { /** * The token to be used to report progress. */ token: ProgressToken; }协议要点见 workDoneProgressCancel.md取消的进度无需在 begin 中标记为cancellable——也就是说即使服务器未提供取消按钮客户端仍然可以主动取消进度客户端可能因多种原因取消进度发生错误、重载工作区等服务器收到该通知后应终止对应任务并发送end通知收尾或依据自身实现决定处理方式。此外对于客户端发起的进度取消则直接通过取消对应请求如$/cancelRequest完成无需单独的 cancel 通知。五、客户端能力协商与向后兼容为保持协议向后兼容服务器只有在客户端通过能力声明明确支持时才能使用window/workDoneProgress/create请求。客户端在 initialize 握手阶段返回的ClientCapabilities中声明window?: { /** * Whether client supports server initiated progress using the * window/workDoneProgress/create request. */ workDoneProgress?: boolean; };对应客户端能力属性为window.workDoneProgress类型为boolean可选。服务器在发起 create 请求前必须检查该能力位若客户端未声明支持服务器应退回到客户端发起的方式或在请求参数中附带的workDoneToken上上报进度甚至放弃进度展示。与之相对客户端发起方式有一个特别之处不存在专门的客户端能力位来声明是否会在每个请求上发送进度 token。因为这在很多客户端中并非静态属性甚至同一请求类型的不同请求实例都可能不同所以客户端能力通过每个请求参数中是否出现workDoneToken属性来按实例动态表达见 types/workDoneProgress.md 中 Client Initiated Progress 一节。同时为避免客户端在发送请求前建立进度 UI 而服务器实际不报进度服务器需要在对应功能的 server capability 中声明workDoneProgress支持例如{ referencesProvider: { workDoneProgress: true } }六、从元模型看协议定义的一致性本仓库在 metaModel 目录 中提供了 LSP 3.17 的机器可读元模型metaModel.json、metaModel.schema.json与对应的 TypeScript 模型metaModel.ts可用于校验与代码生成。其中与本文主题相关的定义包括window/workDoneProgress/create 请求定义messageDirection: serverToClient、result: null、params: WorkDoneProgressCreateParamsWorkDoneProgressCreateParams 结构仅含token: ProgressToken一个属性WorkDoneProgressCancelParams 结构同样仅含token: ProgressTokenProgressToken 类型integer | string。元模型中的这些定义与各 Markdown 规范文档完全一致说明该请求在协议中作为一等公民被完整建模。如果你在实现语言服务器 SDK 时使用元模型驱动代码生成window/workDoneProgress/create会自然生成对应的请求类型、参数类型与文档注释。七、实现建议小结能力先行发送 create 请求前务必检查客户端能力window.workDoneProgress是否为true。token 唯一且单次使用每个进度实例使用独立的ProgressToken遵守一个 begin、多个 report、一个 end的规则。正确处理 create 失败create 请求报错后该 token 立即作废不得再发送任何$/progress通知。响应取消监听window/workDoneProgress/cancel通知收到后尽快终止任务并发送end负载。善用元模型以 metaModel.json 为单一事实来源生成类型定义避免手写结构与规范漂移。通过以上机制语言服务器可以在索引、编译、依赖分析等请求外的长耗时操作中向用户提供可取消、可感知的进度反馈显著改善编辑器的交互体验——这正是 LSP 3.15 引入工作进度机制、并让服务器侧发起进度的设计初衷。赞分享开发工具【免费下载链接】language-server-protocolDefines a common protocol for language servers.项目地址https://gitcode.com/gh_mirrors/la/language-server-protocol点击查看免费下载相关推荐KOReader 上手教程免费在 Kindle 和 Kobo 上读 20 多种电子书格式KOReader 上手教程免费在 Kindle 和 Kobo 上读 20 多种电子书格式 KOReader 是一款免费开源的电子书阅读器主要解决设备自带阅读开发工具TeleChat2.5-35B的vLLM服务化部署实战教程10个步骤快速搭建AI推理服务TeleChat2.5 35B的vLLM服务化部署实战教程10个步骤快速搭建AI推理服务 TeleChat2.5 35B是中国电信人工智能研究院研发的35B参如何快速搭建高效Node.js服务器example-node-server完整指南如何快速搭建高效Node.js服务器example node server完整指南 example node server 是一个基于Babel的轻量级Nod上一篇Klipper实战如何让3D打印机实现智能参数自适应调校下一篇Tkinter表格组件终极指南用tksheet构建专业级数据界面创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
开发工具【免费下载链接】language-server-protocolDefines a common protocol for language servers.项目地址https://gitcode.com/gh_mirrors/la/language-server-protocol点击查看免费下载导读window/workDoneProgress/create是 Language Server ProtocolLSP中由**服务器主动向客户端发起工作进度Work Done Progress**的核心请求解决了服务器在请求上下文之外执行耗时任务如重新索引数据库、批量编译、依赖解析时无法向用户呈现进度的问题。本文基于本仓库_specifications/lsp/3.17目录下的规范文档结合 协议元模型 中对该请求的机器可读定义完整讲解该请求的协议形态、token 生命周期、与$/progress通知的配合方式、取消机制及客户端能力协商帮助你正确实现服务器端的进度上报。一、背景两种工作进度发起方式在 LSP 3.15 及之后版本中进度上报通过通用的$/progress通知完成其值负载value payload有三种形态WorkDoneProgressBegin、WorkDoneProgressReport和WorkDoneProgressEnd对应进度的开始—更新—结束三个阶段详见 类型定义。按发起方不同Work Done Progress 分为两类发起方式触发途径典型场景客户端发起client initiated客户端在请求参数中加入workDoneToken属性客户端发起的textDocument/reference等请求上附带进度 token服务器发起server initiated服务器发送window/workDoneProgress/create请求服务器需要在某个请求之外自行上报进度如后台重新索引数据库本篇文章聚焦第二种方式——服务器发起的进度。二、协议定义方法、参数与响应请求方向与方法名window/workDoneProgress/create是一个从服务器发往客户端server-to-client的请求用于请求客户端创建一个工作进度实例。这一方向性在协议元模型中有明确记录在 metaModel.json 中该请求的messageDirection字段为serverToClientresult类型为null文档注释为Thewindow/workDoneProgress/createrequest is sent from the server to the client to initiate progress reporting from the server.请求参数WorkDoneProgressCreateParams请求参数类型定义如下export interface WorkDoneProgressCreateParams { /** * The token to be used to report progress. */ token: ProgressToken; }其中ProgressToken是integer | string的联合类型见 specification.md 与 metaModel.json。服务器在发起 create 请求时需自行生成一个唯一 token实践中常用 UUID 字符串该 token 将作为后续所有$/progress通知中标识此进度实例的键。响应与错误处理成功响应result为void即无返回值客户端确认已创建进度。错误响应若请求处理过程中发生异常客户端返回error.code与error.message。规范对错误情形有一个关键约束如果 create 请求出错服务器绝不能使用该 token 发送任何进度通知。这保证了错误发生后客户端不会收到与已失败进度关联的幽灵更新是保证进度 UI 一致性的底线规则。三、服务器发起进度的完整生命周期根据 types/workDoneProgress.md 中的Server Initiated Progress一节服务器发起的进度遵循以下完整流程1. 创建进度create服务器在需要上报进度时例如准备开始重索引先向客户端发送{ jsonrpc: 2.0, id: 10, method: window/workDoneProgress/create, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1 } }2. 发送 begin 通知创建成功后服务器通过$/progress通知发送WorkDoneProgressBegin负载title为必填项用于简短说明正在执行的操作类型{ jsonrpc: 2.0, method: $/progress, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1, value: { kind: begin, title: Indexing workspace, cancellable: true, message: Scanning project/src, percentage: 0 } } }WorkDoneProgressBegin的字段语义类型定义字段类型必填说明kindbegin是负载形态标记titlestring是进度的标题如Indexing或Linking dependenciescancellableboolean否是否显示取消按钮不支持取消的客户端可忽略messagestring否更详细的进度消息如3/25 files未设置时沿用上一次消息percentageuinteger否进度百分比100视为 100%不提供则视为无限进度取值范围[0, 100]应保持单调递增3. 周期性发送 report 通知任务执行过程中服务器发送WorkDoneProgressReport更新进度{ jsonrpc: 2.0, method: $/progress, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1, value: { kind: report, message: 12/50 files, percentage: 24 } } }WorkDoneProgressReport支持cancellable、message、percentage三个可选字段其中cancellable仅在 begin 中请求了取消按钮时有效。4. 发送 end 通知收尾任务完成或失败时发送WorkDoneProgressEnd{ jsonrpc: 2.0, method: $/progress, params: { token: 2f8a4c12-9d3b-4e76-9c1a-7b0f3a56e2d1, value: { kind: end, message: Indexing finished } } }WorkDoneProgressEnd仅含可选的message字段可用于说明操作结果。token 的使用约束规范明确要求create 请求中提供的 token 只能使用一次——即对该 token 应恰好发送一个begin、任意多个report和一个end通知。这与客户端发起的进度形成对比客户端通过请求参数中的workDoneToken传入的 token其有效期只持续到该请求返回响应为止。四、取消机制window/workDoneProgress/cancel服务器发起的进度同样支持取消。客户端通过window/workDoneProgress/cancel通知client-to-server 方向取消进度参数类型为export interface WorkDoneProgressCancelParams { /** * The token to be used to report progress. */ token: ProgressToken; }协议要点见 workDoneProgressCancel.md取消的进度无需在 begin 中标记为cancellable——也就是说即使服务器未提供取消按钮客户端仍然可以主动取消进度客户端可能因多种原因取消进度发生错误、重载工作区等服务器收到该通知后应终止对应任务并发送end通知收尾或依据自身实现决定处理方式。此外对于客户端发起的进度取消则直接通过取消对应请求如$/cancelRequest完成无需单独的 cancel 通知。五、客户端能力协商与向后兼容为保持协议向后兼容服务器只有在客户端通过能力声明明确支持时才能使用window/workDoneProgress/create请求。客户端在 initialize 握手阶段返回的ClientCapabilities中声明window?: { /** * Whether client supports server initiated progress using the * window/workDoneProgress/create request. */ workDoneProgress?: boolean; };对应客户端能力属性为window.workDoneProgress类型为boolean可选。服务器在发起 create 请求前必须检查该能力位若客户端未声明支持服务器应退回到客户端发起的方式或在请求参数中附带的workDoneToken上上报进度甚至放弃进度展示。与之相对客户端发起方式有一个特别之处不存在专门的客户端能力位来声明是否会在每个请求上发送进度 token。因为这在很多客户端中并非静态属性甚至同一请求类型的不同请求实例都可能不同所以客户端能力通过每个请求参数中是否出现workDoneToken属性来按实例动态表达见 types/workDoneProgress.md 中 Client Initiated Progress 一节。同时为避免客户端在发送请求前建立进度 UI 而服务器实际不报进度服务器需要在对应功能的 server capability 中声明workDoneProgress支持例如{ referencesProvider: { workDoneProgress: true } }六、从元模型看协议定义的一致性本仓库在 metaModel 目录 中提供了 LSP 3.17 的机器可读元模型metaModel.json、metaModel.schema.json与对应的 TypeScript 模型metaModel.ts可用于校验与代码生成。其中与本文主题相关的定义包括window/workDoneProgress/create 请求定义messageDirection: serverToClient、result: null、params: WorkDoneProgressCreateParamsWorkDoneProgressCreateParams 结构仅含token: ProgressToken一个属性WorkDoneProgressCancelParams 结构同样仅含token: ProgressTokenProgressToken 类型integer | string。元模型中的这些定义与各 Markdown 规范文档完全一致说明该请求在协议中作为一等公民被完整建模。如果你在实现语言服务器 SDK 时使用元模型驱动代码生成window/workDoneProgress/create会自然生成对应的请求类型、参数类型与文档注释。七、实现建议小结能力先行发送 create 请求前务必检查客户端能力window.workDoneProgress是否为true。token 唯一且单次使用每个进度实例使用独立的ProgressToken遵守一个 begin、多个 report、一个 end的规则。正确处理 create 失败create 请求报错后该 token 立即作废不得再发送任何$/progress通知。响应取消监听window/workDoneProgress/cancel通知收到后尽快终止任务并发送end负载。善用元模型以 metaModel.json 为单一事实来源生成类型定义避免手写结构与规范漂移。通过以上机制语言服务器可以在索引、编译、依赖分析等请求外的长耗时操作中向用户提供可取消、可感知的进度反馈显著改善编辑器的交互体验——这正是 LSP 3.15 引入工作进度机制、并让服务器侧发起进度的设计初衷。赞分享开发工具【免费下载链接】language-server-protocolDefines a common protocol for language servers.项目地址https://gitcode.com/gh_mirrors/la/language-server-protocol点击查看免费下载相关推荐KOReader 上手教程免费在 Kindle 和 Kobo 上读 20 多种电子书格式KOReader 上手教程免费在 Kindle 和 Kobo 上读 20 多种电子书格式 KOReader 是一款免费开源的电子书阅读器主要解决设备自带阅读开发工具TeleChat2.5-35B的vLLM服务化部署实战教程10个步骤快速搭建AI推理服务TeleChat2.5 35B的vLLM服务化部署实战教程10个步骤快速搭建AI推理服务 TeleChat2.5 35B是中国电信人工智能研究院研发的35B参如何快速搭建高效Node.js服务器example-node-server完整指南如何快速搭建高效Node.js服务器example node server完整指南 example node server 是一个基于Babel的轻量级Nod上一篇Klipper实战如何让3D打印机实现智能参数自适应调校下一篇Tkinter表格组件终极指南用tksheet构建专业级数据界面创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
