任务投放、审批和执行反馈

运营人员创建任务时配置“给设备下发什么”；规则服务决定“哪些设备符合条件”；BPM 决定配置修改何时生效；设备回调则回答“是否已经推送、之后是否上报运行”。因此任务主表和设备关系表不能互相替代，也不能把推送成功当作应用运行成功。

业务对象与关系

Mermaid Diagram Code:

flowchart LR
  F[infra 文件元数据] -->|infra_file_id| T[base_task_device 任务]
  R[rule 业务规则绑定] -->|TASK_PUSH 和业务ID| T
  B[bpm 流程实例] -->|审批结果事件| T
  T -->|task_id| D[flow_task_device 设备执行状态]
  T -->|task_id| A[flow_task_role 数据权限]
  S[system 角色] -->|role_id| A
  DEV[device 设备身份] -->|MAC 逻辑关联| D
  CB[设备推送回调] --> D
  RUN[应用运行事件] -->|首次运行报告时间| D

图中箭头均是代码逻辑关联；本页涉及的4张主业务表及下载表在本次快照中没有物理外键。nebula_ids 中其他历史表存在物理外键，不能推广成整个库无外键。

表	业务作用和读写方	关键字段与实测索引
base_task_device	Task 管理接口创建、修改、审批落地；设备拉取任务时读取	id主键；task_type保留历史广告0、APP1、launcher2编码；infra_file_id取文件元信息；status=0允许投放、1停止；当前仅主键索引
flow_task_device	运营维护目标/黑白名单，Task回调消费者更新推送结果，运行消费者补首次运行时间	task_id + mac定位某设备某任务；唯一索引mac(mac,task_id)支撑重复回调更新；idx_ftd_task_id_push_success(task_id,is_push_success)支撑任务反馈查询
flow_task_role	TaskRoleService 维护任务的数据权限，任务列表按角色筛选	task_id关联任务、role_id关联system角色；仅id主键，当前无二列唯一约束
flow_app_download	AppDownloadConsumer 接收下载上报后写入，后台查下载明细	mac/cpu_id标识设备，package_name和版本定位应用，record_time为设备记录时间；仅id主键

下载表真实字段名为 vsersion_code，实体为 vsersionCode，拼写虽不规范但源码与实库一致。整理文档不将其改写成另一个不存在的字段。物理字段全表见遗留库附录。

从编辑到生效

TaskServiceImpl和TaskNoBpmServiceImpl分别保留需要审批与不走审批的管理路径。审批路径把待修改字段保存在draft，通过process_instance_id关联BPM流程。TaskBpmServiceImpl.createBpm将任务ID作为businessKey，并携带规则业务信息；BpmTaskStatusListener接收结果后委托handleBpmResult。非通过结果只更新流程状态，通过后按原valid处理新增、修改、移除，并更新缓存与关联业务。

这里的valid不是普通Boolean：当前Task业务使用BpmBusinessValid枚举，0未生效、1已生效、2已生效待修改、3已生效待移除、4待启用、5待禁用。实体上的“0有效、1无效”旧注释不再能解释当前Task审批逻辑。bpm_status是流程状态，status是投放开关；三者不能共用一套字典。

draft经BpmDraftTypeHandler映射；设备关联实体允许draft=null表示无待审草稿。release_info仍保留历史发布配置快照字段，但当前V2投放先调用RuleRunUtil.matchBusinessIds(TASK_PUSH, device)取得业务ID，再读取任务并过滤status。旧task_rule_id、filter_type及遗留规则关系表的存在，并不等于当前投放仍以旧表关联为唯一依据。

V2响应外层taskType由buildUpdateTaskMap固定写为1，源码说明重构后该投放路径负责UOTA推送；因此实体保留的三类历史编码不能直接解释为V2仍提供三种独立投放策略。APP文件版本来自infra文件，taskVersionCode来自任务自身version_code用于终端判断配置更新，两种版本也不能混用。

回调与运行确认

设备事件入口将普通任务回调发送到task-call-back，APP任务另补文件包名和版本后发送apk-push-callback。两类Task消费者都调用TaskDeviceService.batchInsertOrUpdate，XML按(mac,task_id)唯一键更新推送时间和黑白名单标记。APP专用消费者明确只处理任务状态，不承担其他服务的历史索引存储。

app_install_report_time、app_runtime_report_device_time、app_runtime_report_sys_time用于区分安装列表上报和运行上报；后两项分别保存设备时间和服务端接收时间。当前AppRuntimeConsumer在推送成功且首次运行时间尚不完整时更新这些字段，这与运行明细入TDengine是两项独立处理。源码路径可确认写入逻辑，未验证消息投递、缓存刷新或数据一致性的运行效果。

Task统计成功设备时，还通过LauncherConfigApi.writeMacToRedisSetByTaskId合并launcher广告推送得到的MAC。TaskDeviceServiceImpl.java:293先取flow_task_device中此任务的成功MAC，:300请求launcher加入同一Redis Set，再按集合去重。这是跨服务汇总，不能只看Task关系表就断言得到完整投放设备数；也没有跨库物理外键保证该关联。

源码证据（路径基准见总览）：dal/dataobject/task/TaskDO.java:20、dal/dataobject/taskdevice/TaskDeviceDO.java:21、service/task/TaskServiceImpl.java:475、service/task/TaskBpmServiceImpl.java:86与:429、listener/BpmTaskStatusListener.java:29、kafka/consumer/TaskPushCallbackConsumer.java:32、kafka/consumer/ApkPushCallbackConsumer.java:44、kafka/consumer/AppRuntimeConsumer.java:108、mapper/taskdevice/TaskDeviceMapper.xml:12。枚举位于ik_project/yudao-cloud/yudao-module-bpm/yudao-module-bpm-api/src/main/java/cn/iocoder/yudao/module/bpm/enums/business/BpmBusinessValid.java:20。