配送取消后又出现ret_任务：Uber Direct返程为何需要单独识别

一笔配送被取消以后，系统里又出现另一条配送记录，并不一定是把原任务重复建了一遍。Uber Direct的Delivery Status Webhook文档说明，在发生返程时，会为返回行程自动创建新配送。理解这层关系，需要把“原配送”和“返程配送”同时看见。

原页的重点说明直接区分标识：原配送ID以del_开头，返回配送ID以ret_开头；返程信息会出现在webhook响应的return对象中。[1] 这段文字说明两个任务身份，并没有把返程处理压缩成原任务的一次简单改名。

状态定义也保留取消与返回的差别。canceled可以来自取消接口、Direct Dashboard或内部原因；returned的说明则关联配送取消后，为把物品送回寄件方而创建的新配送。[1] 因此，孤立看到canceled，不能自行补成“物品已经返回寄件人”，也不能仅凭取消这一事件推定返程结果。

文档另以related_deliveries描述有关联的配送集合，其中包含相关配送ID和关系类型；original表示正向行程，returned表示返向行程。[1] 这里的returned是关系值的用途。阅读资料时，应保留字段名，避免把关系标签直接当成某次返程已完成的状态证明。

设想一份专为说明编写的交接记录，列出原配送标识、相关返程标识，以及各自已经观察到的状态。读者由此知道是在讨论哪一段；若只保留原配送的取消状态，返回物品的后续记录就容易被遮住。本例没有对应真实包裹，也没有创建返程或决定司机应采取什么行动。

同一份webhook文档还区分事件实例的id与delivery_id：前者标识这一条事件，后者标识事件所适用的配送。[1] 把事件号写成配送号，会再增加一层对象混淆。它们可以出现在同一条消息里，但共同出现不意味着用途相同。

正文的示例响应含有历史示例时间和示意数据，本篇没有把这些内容当作2026年的实际配送记录，也没有拿其中地址、费用或时间估算当前服务表现。页面未明确首次发布日期，本文只解释本次读取版本中有明确文字支持的身份与关联关系。

对同城配送的信息交接来说，说明“哪个任务发生了什么”比只摘一个状态词更完整。本篇没有调用配送接口，不涉及取消权限、赔付、返程价格、驾驶或货物安全操作。真实货物当前在哪里，仍要由相应任务的实际记录回答，不能从任务前缀或原单取消状态直接推算。