[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$apiParty6fBuHLCPZ1LTYs42XHdVbjpSDOYYPYzyxeAGwSN5Tp8":3,"$apiPartykNfcBBrETpXAzwvcFn--PcfRspmf71vj29M5G-sYrUI":563,"$apiPartykNfcBBrETpXAzwvcFn--PcfRspmf71vj29M5G-sYrUI$H93EERW16b":563},{"product_data":4,"scene_data":21,"task_data":407,"modality_data":441,"domain_data":478},[5,9,12,15,18],{"name":6,"value":7,"add_value":8,"describe":8},"Rivo","1","",{"name":10,"value":11,"add_value":8,"describe":8},"Cubo","2",{"name":13,"value":14,"add_value":8,"describe":8},"Moye","3",{"name":16,"value":17,"add_value":8,"describe":8},"Juro","4",{"name":19,"value":20,"add_value":8,"describe":8},"Ordo","5",[22,73,135,197,232,267,302,337,372],{"name":23,"value":7,"add_value":24,"describe":25,"children":26},"Home & Indoor","sofa","AI enhances everyday home life. Our datasets cover real indoor scenes to support smart devices, robotics, and home intelligence.",[27,29,31,33,35,37,40,43,46,49,52,55,58,61,64,67,70],{"name":28,"value":7},"Living Room",{"name":30,"value":11},"Bedroom",{"name":32,"value":14},"Kitchen",{"name":34,"value":17},"Dining Area",{"name":36,"value":20},"Bathroom",{"name":38,"value":39},"Entrance \u002F Foyer","6",{"name":41,"value":42},"Corridor \u002F Hallway","7",{"name":44,"value":45},"Staircase","8",{"name":47,"value":48},"Home Office","9",{"name":50,"value":51},"Hobby \u002F Game Room","10",{"name":53,"value":54},"Worship Space","11",{"name":56,"value":57},"Garage","12",{"name":59,"value":60},"Utility \u002F Laundry Room","13",{"name":62,"value":63},"Pantry","14",{"name":65,"value":66},"Basement","15",{"name":68,"value":69},"Garden","16",{"name":71,"value":72},"Balcony","17",{"name":74,"value":11,"add_value":75,"describe":76,"children":77},"Office & Educational","workshop","AI is reshaping work and learning. Our datasets capture offices and classrooms to power automation and next-generation productivity tools.",[78,81,84,87,90,93,96,99,102,105,108,111,114,117,120,123,126,129,132],{"name":79,"value":80},"Open Office","18",{"name":82,"value":83},"Private Office","19",{"name":85,"value":86},"Co-working Space","20",{"name":88,"value":89},"Reception \u002F Lobby","21",{"name":91,"value":92},"Conference Room","22",{"name":94,"value":95},"Huddle Room \u002F Booth","23",{"name":97,"value":98},"Lecture Hall \u002F Auditorium","24",{"name":100,"value":101},"Classroom","25",{"name":103,"value":104},"Science Laboratory","26",{"name":106,"value":107},"Library","27",{"name":109,"value":110},"Design Studio","28",{"name":112,"value":113},"Pantry \u002F Breakroom","29",{"name":115,"value":116},"Cafeteria \u002F Canteen","30",{"name":118,"value":119},"Restroom (Commercial)","31",{"name":121,"value":122},"Gymnasium \u002F Sports Hall","32",{"name":124,"value":125},"Server Room","33",{"name":127,"value":128},"Mailroom \u002F Logistics","34",{"name":130,"value":131},"Janitorial Closet","35",{"name":133,"value":134},"Corridor \u002F Elevators","36",{"name":136,"value":14,"add_value":137,"describe":138,"children":139},"Healthcare & Medical","love-and-help","AI is advancing modern healthcare. Our datasets include clinics and hospitals to enable clinical insights and medical automation.",[140,143,146,149,152,155,158,161,164,167,170,173,176,179,182,185,188,191,194],{"name":141,"value":142},"Operating Theatre \u002F OR","37",{"name":144,"value":145},"Consultation Room","38",{"name":147,"value":148},"Treatment Room","39",{"name":150,"value":151},"Dental Clinic","40",{"name":153,"value":154},"Inpatient Ward","41",{"name":156,"value":157},"Nurse Station","42",{"name":159,"value":160},"ICU","43",{"name":162,"value":163},"NICU (Neonatal ICU)","44",{"name":165,"value":166},"Emergency Room (ER)","45",{"name":168,"value":169},"Hospital Corridor","46",{"name":171,"value":172},"Waiting Area","47",{"name":174,"value":175},"CT\u002FMRI","48",{"name":177,"value":178},"Medical Laboratory","49",{"name":180,"value":181},"Phlebotomy Room","50",{"name":183,"value":184},"Rehabilitation Gym","51",{"name":186,"value":187},"Assisted Living Room","52",{"name":189,"value":190},"Pharmacy","53",{"name":192,"value":193},"Sterile Processing Dept","54",{"name":195,"value":196},"Medical Storage","55",{"name":198,"value":17,"add_value":199,"describe":200,"children":201},"Business & Public Service","business","AI is elevating commercial and public services. Our datasets span retail, dining, and service centers to improve intelligent operations.",[202,205,208,211,214,217,220,223,226,229],{"name":203,"value":204},"Shopping Mall Atrium","86",{"name":206,"value":207},"Supermarket Shelf","87",{"name":209,"value":210},"Self-Checkout Counter","88",{"name":212,"value":213},"Restaurant Dining Hall","89",{"name":215,"value":216},"Commercial Kitchen","90",{"name":218,"value":219},"Hotel Lobby","91",{"name":221,"value":222},"Subway Platform","92",{"name":224,"value":225},"Security Checkpoint","93",{"name":227,"value":228},"Underground Parking","94",{"name":230,"value":231},"Bank Teller Zone","95",{"name":233,"value":20,"add_value":234,"describe":235,"children":236},"Industrial & Manufacturing","robot-arm","AI is modernizing industry. Our datasets capture factories and logistics spaces to support robotics and intelligent manufacturing.",[237,240,243,246,249,252,255,258,261,264],{"name":238,"value":239},"Final Assembly Line","96",{"name":241,"value":242},"Quality Control Station","97",{"name":244,"value":245},"Robotic Welding Cell","98",{"name":247,"value":248},"CNC Machining Center","99",{"name":250,"value":251},"Cleanroom","100",{"name":253,"value":254},"Automated Warehouse","101",{"name":256,"value":257},"Loading Dock","102",{"name":259,"value":260},"Sorting Center","103",{"name":262,"value":263},"Chemical Plant","104",{"name":265,"value":266},"Power Substation","105",{"name":268,"value":39,"add_value":269,"describe":270,"children":271},"Transportation & Driving","car","AI is revolutionizing mobility. Our datasets capture road networks, vehicle dynamics and traffic scenarios to support autonomous driving and intelligent transportation systems.",[272,275,278,281,284,287,290,293,296,299],{"name":273,"value":274},"Urban Intersection","56",{"name":276,"value":277},"Highway \u002F Expressway","57",{"name":279,"value":280},"Tunnel","58",{"name":282,"value":283},"Roundabout","59",{"name":285,"value":286},"School \u002F Hospital Zone","60",{"name":288,"value":289},"Toll Station","61",{"name":291,"value":292},"Construction Zone","62",{"name":294,"value":295},"Parking Garage","63",{"name":297,"value":298},"Driver Cabin","64",{"name":300,"value":301},"Adverse Weather","65",{"name":303,"value":42,"add_value":304,"describe":305,"children":306},"Outdoor & Construction","tent-tree","AI is optimizing outdoor operations. Our datasets capture construction sites, open-air work zones and outdoor infrastructure to support smart construction and autonomous outdoor machinery.",[307,310,313,316,319,322,325,328,331,334],{"name":308,"value":309},"Excavation Site","66",{"name":311,"value":312},"Scaffolding Area","67",{"name":314,"value":315},"Material Storage Yard","68",{"name":317,"value":318},"Site Entrance","69",{"name":320,"value":321},"Roadwork Zone","70",{"name":323,"value":324},"Bridge Infrastructure","71",{"name":326,"value":327},"Transmission Line","72",{"name":329,"value":330},"Open-pit Mine","73",{"name":332,"value":333},"Tunneling Site","74",{"name":335,"value":336},"Post-Disaster Rubble","75",{"name":338,"value":45,"add_value":339,"describe":340,"children":341},"Nature, Aerial & Aquatic","global-loop","AI is exploring the natural world. Our datasets capture terrestrial landscapes, aerial vistas and aquatic ecosystems to support environmental monitoring and autonomous exploration systems.",[342,345,348,351,354,357,360,363,366,369],{"name":343,"value":344},"Deep Forest","76",{"name":346,"value":347},"Farmland \u002F Crops","77",{"name":349,"value":350},"River \u002F Lake","78",{"name":352,"value":353},"Open Ocean","79",{"name":355,"value":356},"Underwater Coral Reef","80",{"name":358,"value":359},"Fish Farm","81",{"name":361,"value":362},"Mountain Terrain","82",{"name":364,"value":365},"Urban Low Altitude","83",{"name":367,"value":368},"Fire Scene","84",{"name":370,"value":371},"Desert \u002F Gobi","85",{"name":373,"value":48,"add_value":374,"describe":375,"children":376},"Virtul & Digital","siri","AI is reshaping the virtual realm. Our datasets capture digital twins, virtual environments and simulated spaces to support metaverse development and intelligent digital interaction.",[377,380,383,386,389,392,395,398,401,404],{"name":378,"value":379},"VR Social Space","106",{"name":381,"value":382},"Synthetic Driving Sim","107",{"name":384,"value":385},"Digital Twin City","108",{"name":387,"value":388},"FPS \u002F MOBA Game","109",{"name":390,"value":391},"Robotics Gym","110",{"name":393,"value":394},"AR Navigation","111",{"name":396,"value":397},"Virtual Showroom","112",{"name":399,"value":400},"Code \u002F IDE Interface","113",{"name":402,"value":403},"App GUI Screen","114",{"name":405,"value":406},"Synthetic Face\u002FID","115",[408,411,414,417,420,423,426,429,432,435,438],{"name":409,"value":7,"add_value":410,"describe":8},"Classification","rubric",{"name":412,"value":11,"add_value":413,"describe":8},"Detection","radar",{"name":415,"value":14,"add_value":416,"describe":8},"Segmentation","segmentation",{"name":418,"value":17,"add_value":419,"describe":8},"Tacking","crosshairs",{"name":421,"value":20,"add_value":422,"describe":8},"Estimation","streamline",{"name":424,"value":39,"add_value":425,"describe":8},"QA","qa",{"name":427,"value":42,"add_value":428,"describe":8},"Recognition","finger-scan",{"name":430,"value":45,"add_value":431,"describe":8},"Control","control",{"name":433,"value":48,"add_value":434,"describe":8},"Extraction","extraction",{"name":436,"value":51,"add_value":437,"describe":8},"Retrieval","retrieval",{"name":439,"value":54,"add_value":440,"describe":8},"Forecast","forecast",[442,445,448,451,454,457,460,463,466,469,472,475],{"name":443,"value":7,"add_value":444,"describe":8},"Audio","audio",{"name":446,"value":11,"add_value":447,"describe":8},"Image","image",{"name":449,"value":14,"add_value":450,"describe":8},"Text","text",{"name":452,"value":17,"add_value":453,"describe":8},"Video","video",{"name":455,"value":20,"add_value":456,"describe":8},"Multi","multi",{"name":458,"value":39,"add_value":459,"describe":8},"Document","document",{"name":461,"value":42,"add_value":462,"describe":8},"Time-Series","time-series",{"name":464,"value":45,"add_value":465,"describe":8},"3D cloud","cloud",{"name":467,"value":48,"add_value":468,"describe":8},"Code","code",{"name":470,"value":51,"add_value":471,"describe":8},"Event","event",{"name":473,"value":54,"add_value":474,"describe":8},"Motion","motion",{"name":476,"value":57,"add_value":477,"describe":8},"Interaction","interaction",[479,482,487,491,494,499,504,509,514,519,524,528,532,536,540,544,548,552,556,559],{"id":480,"value":480,"name":233,"intro":481,"add_value":234,"describe":481},2,"智能质检：利用图像识别、多模态模型对产品外观或声音、振动等数据进行分析，自动识别缺陷，提高质量控制效率。\n工业知识问答与文档理解：通过大模型理解和总结技术文档、操作手册，实现快速问答、知识检索和培训支持。\n安全监测与风险预警：实时分析视频、传感器和操作日志，识别潜在危险行为或异常状态，提前预警，保障人员和设备安全。",{"id":483,"value":483,"name":484,"intro":485,"add_value":486,"describe":485},3,"Finance & Insurance","风险评估与预测：分析大量客户数据，评估信用风险、市场风险等，预测违约概率、股价走势等，辅助金融机构决策。\n智能投顾：根据客户风险偏好、资产状况等，提供个性化投资组合建议，实时调整投资策略。\n反欺诈检测：通过分析交易数据、用户行为，识别异常交易和欺诈行为，保障金融安全。","funds",{"id":488,"value":488,"name":489,"intro":490,"add_value":269,"describe":490},1,"Transport & Automotive","智能座舱：打造多模态交互的 AI 座舱，通过语音、手势、面部识别等实现人机交互，如语音控制导航、音乐播放。\n驾驶员状态监测：识别疲劳、分心、抽烟、打电话等行为，通过大模型判断危险等级，触发相应提醒或干预机制。\n智能驾驶：AI 用于环境感知、路径规划与决策控制，使车辆能识别道路、行人、障碍物等，实现自适应巡航、自动泊车、车道保持等功能，提升驾驶安全性与便利性。",{"id":492,"value":492,"name":136,"intro":493,"add_value":137,"describe":493},4,"医学影像诊断：分析 CT、MRI 等影像，辅助医生检测疾病、识别病灶，如 AI 系统可快速发现肺部结节。\n医患对话助手：通过自然语言处理理解患者问题，提供初步健康建议或就诊指导，缓解医生接诊压力。\n智能健康管理：根据用户健康数据，提供个性化健康建议、疾病预警，如智能手环结合 AI 分析用户运动、睡眠、心率等数据。",{"id":495,"value":495,"name":496,"intro":497,"add_value":498,"describe":497},6,"Smart Devices","多模态交互：支持语音、手势、眼神等多种交互方式，如 AI 眼镜可通过语音指令实现翻译、搜索功能。\n智能感知与处理：使设备能感知环境、理解用户需求，如智能音箱根据环境噪音自动调节音量。\n个性化服务：根据用户使用习惯和偏好，提供个性化功能与服务，如智能手表为用户定制运动健身计划。","microscope",{"id":500,"value":500,"name":501,"intro":502,"add_value":503,"describe":502},8,"Law & Government","智能法律问答：面向公众或企业用户，提供合规、劳动法、婚姻继承、知识产权等常见法律问题的智能解答。\n合同审查与风险识别：利用大模型分析合同内容，识别潜在风险条款、漏洞或不合理约定，提升合同审核质量。\n法律知识图谱构建：自动梳理法规、案例、条文之间的引用关系，构建语义化知识图谱，支持智能分析和推理。","hammer",{"id":505,"value":505,"name":506,"intro":507,"add_value":508,"describe":507},7,"Education & Training","个性化学习：根据学生学习进度、能力和知识掌握情况，推送个性化学习内容与练习，如智能辅导系统为学生制定专属学习计划。\n智能教学辅助：AI 助教协助教师进行作业批改、答疑解惑，还可分析教学数据，为教师提供教学反馈，优化教学方法。\n虚拟学习环境：利用 AI 创建虚拟实验、历史场景等，让学生沉浸式学习，如在虚拟化学实验室中进行实验操作。","degree-hat",{"id":510,"value":510,"name":511,"intro":512,"add_value":513,"describe":512},5,"Agriculture & Food","作物病虫害识别与防治：通过图像识别分析农作物叶片、果实等症状，识别病虫害类型，给出防治建议，减少产量损失。\n农产品质量检测：利用图像和传感器数据，识别果蔬等农产品的成熟度、外观缺陷，进行自动分级，提高市场竞争力。\n农情监测与预测：利用卫星遥感、气象和传感器数据，结合大模型预测作物长势、干旱、洪涝等农情变化。","ph-farm",{"id":515,"value":515,"name":516,"intro":517,"add_value":518,"describe":517},9,"Retail & E-commerce","智能客服：通过自然语言对话理解用户需求，提供产品推荐、订单查询、退换货支持等服务，提升客户满意度。\n个性化营销推荐：基于用户浏览、购买、偏好等行为数据，生成个性化推荐内容与优惠策略，提高转化率和客单价。\n商品内容生成：自动撰写商品标题、卖点描述、使用说明等内容，适用于海量SKU的内容生产与多语言发布。","buy",{"id":520,"value":520,"name":521,"intro":522,"add_value":523,"describe":8},10,"Security & Protection",null,"safe-shield-line",{"id":525,"value":525,"name":526,"intro":522,"add_value":527,"describe":8},11,"Environment & Climate","weather",{"id":529,"value":529,"name":530,"intro":522,"add_value":531,"describe":8},12,"Energy & Resource","energy-leaf",{"id":533,"value":533,"name":534,"intro":522,"add_value":535,"describe":8},13,"Express & Logistics","speed-outline",{"id":537,"value":537,"name":538,"intro":522,"add_value":539,"describe":8},15,"Sports","baseball-outline",{"id":541,"value":541,"name":542,"intro":522,"add_value":543,"describe":8},16,"General Data","daily-booth",{"id":545,"value":545,"name":546,"intro":522,"add_value":547,"describe":8},17,"Content & Media","media",{"id":549,"value":549,"name":550,"intro":522,"add_value":551,"describe":8},18,"Construction","construction",{"id":553,"value":553,"name":554,"intro":522,"add_value":555,"describe":8},19,"IT & Telecom","tech",{"id":557,"value":557,"name":558,"intro":522,"add_value":498,"describe":8},20,"Science & Research",{"id":560,"value":560,"name":561,"intro":522,"add_value":562,"describe":8},21,"Language & Culture","lang",{"id":564,"unique_code":565,"title":566,"icon":8,"intro":567,"cate":483,"detail":568,"create_time":569,"update_time":570,"price":571,"view_count":572,"download_count":573,"unit":573,"amount":574,"is_create_order":573,"enterprise_id":488,"seo_keywords":575,"seo_description":576,"data_format":577,"file_size":578,"apply_scene":579,"training_task":580,"version":581,"dataset_type_id":492,"dataset_scene_id":553,"sample_file":582,"banner":8,"unit_name":8,"cate_name":449,"icon_url":8,"banner_url":8,"sample_file_url":8,"data_dict":583,"qa_list":626,"sample_metadatas":643,"text_sample_content":683,"enterprise_name":684,"enterprise_logo":685,"data_distribution":686},1120,"95c9cfb21d8b452245ea15cd9279b0f7","Notification Retry and Fallback Code Reasoning Dataset","Train models to trace code dependencies, control flow, and delivery outcomes when notifications fail and retry or switch channels.","\u003Cp>Designed for enterprise notification and broadcast communication platforms, this dataset contains source code examples involving notification delivery, failure retries, fallback channels, idempotency, and state transitions. Structured analyses guide models to infer control flow, component dependencies, and delivery states, and to assess how key logic or code changes affect delivery behavior. It is suitable for supervised fine-tuning and evaluation of code reasoning and dependency understanding for notification systems.\u003C\u002Fp>","2026-10-10 15:21:49","2026-10-19 18:04:45","0.00",41,0,5000,"notification retry code, notification fallback dataset, code reasoning dataset, dependency reasoning, enterprise notification platform, idempotency analysis, control flow analysis, code SFT","A code reasoning dataset for enterprise notification platforms, covering failure retries, fallback channels, idempotency, component dependencies, and delivery","JSON","0.5GB","notification delivery systems, message retry management, notification reliability optimization","code dependency analysis, control flow reasoning, failure recovery analysis","V1.0","rivo\u002Fsample-packages\u002F59425b88-ff1b-4fa0-a4e5-fa38c965fcaa\u002F20261010.zip",[584,589,594,600,605,611,616,621],{"id":573,"name":585,"field":586,"intro":587,"type":588},"File Name","file_name","File name","string",{"id":590,"name":591,"field":592,"intro":593,"type":588},8136,"Source Code","source_code","A source code example related to notification delivery, retries, fallback channels, idempotency, or state transitions.",{"id":595,"name":596,"field":597,"intro":598,"type":599},8137,"State Transitions","state_transitions","Lists state changes in the notification delivery process that can be inferred from the code and the conditions that trigger them.","array",{"id":601,"name":602,"field":603,"intro":604,"type":588},8138,"Idempotency Analysis","idempotency_analysis","Explains how the code prevents duplicate delivery caused by retries or repeated requests, including relevant idempotency keys or state checks; explicitly notes when these mechanisms are not present.",{"id":606,"name":607,"field":608,"intro":609,"type":610},8139,"Control Flow Analysis","control_flow_analysis","Infers the main control flow and branch conditions in the notification delivery process from the source code.","object",{"id":612,"name":613,"field":614,"intro":615,"type":599},8140,"Component Dependencies","component_dependencies","Identifies the components involved in notification delivery and the dependencies among them.",{"id":617,"name":618,"field":619,"intro":620,"type":588},8141,"Delivery Behavior Impact","delivery_behavior_impact","Analyzes how code changes or key logic affect success rates, duplicate delivery, latency, channel selection, and final delivery outcomes, citing the basis for each inference.",{"id":622,"name":623,"field":624,"intro":625,"type":610},8142,"Retry and Fallback Analysis","retry_and_fallback_analysis","Analyzes retry strategies and fallback channel behavior after notification delivery failures.",[627,631,635,639],{"id":628,"question":629,"answer":630},5930,"What does the dataset contain?","The dataset focuses on enterprise notification delivery and includes source code examples with analysis fields for control flow, component dependencies, retries and fallbacks, idempotency, state transitions, and delivery behavior impacts. The exact examples depend on the available data package.",{"id":632,"question":633,"answer":634},5931,"Which capabilities is the dataset suited to training?","It can be used to train and evaluate models on notification-related code reasoning, including tracing delivery flows and branch conditions, identifying component dependencies, explaining retries or fallback channel selection after failures, and assessing how logic changes affect delivery outcomes.",{"id":636,"question":637,"answer":638},5932,"How can I access the dataset?","Check the dataset product page for available packages, delivery formats, and access options. Its fields are organized to support processing source code examples alongside their corresponding analyses; refer to the product page for the specifications actually offered.",{"id":640,"question":641,"answer":642},5933,"What are the licensing and usage terms?","The permitted uses, commercial rights, and redistribution restrictions depend on the license applicable to this dataset. Review the product page or accompanying agreement before use, and confirm that your intended training, evaluation, or internal deployment complies with the terms.",[644,659,671],{"id":645,"relate_table":646,"relate_id":647,"file_size":573,"file_name":648,"path":8,"duration":573,"cate":483,"file_format":649,"audio_rate":8,"audio_channel":522,"audio_bit_depth":522,"quality":8,"annotation":650,"cate_name":651,"source_code":652,"state_transitions":653,"idempotency_analysis":654,"control_flow_analysis":655,"component_dependencies":656,"delivery_behavior_impact":657,"retry_and_fallback_analysis":658},14761,"union_cubo",1485742477,"样例_3.json","json","{\"source_code\": \"type Channel = 'email' | 'sms';\\ntype JobStatus = 'queued' | 'retry_wait' | 'sending' | 'delivered' | 'failed';\\ntype SendResult = { ok: true } | { ok: false; retryable: boolean };\\n\\ninterface DeliveryJob {\\n  id: string;\\n  channel: Channel;\\n  attempts: number;\\n  recipient: string;\\n  payload: string;\\n}\\ninterface JobRepository {\\n  \u002F\u002F Atomically claims a due queued or retry_wait job and moves it to sending.\\n  claimDue(jobId: string): Promise\u003Cboolean>;\\n  schedule(jobId: string, update: { status: 'retry_wait' | 'queued'; channel: Channel; attempts: number; runAt: number }): Promise\u003Cvoid>;\\n  complete(jobId: string, status: 'delivered' | 'failed'): Promise\u003Cvoid>;\\n}\\ninterface Provider {\\n  send(recipient: string, payload: string): Promise\u003CSendResult>;\\n}\\n\\nclass QueueWorker {\\n  constructor(private jobs: JobRepository, private providers: Record\u003CChannel, Provider>) {}\\n\\n  async process(job: DeliveryJob): Promise\u003Cvoid> {\\n    if (!(await this.jobs.claimDue(job.id))) return;\\n    const result = await this.providers[job.channel].send(job.recipient, job.payload);\\n    if (result.ok) {\\n      await this.jobs.complete(job.id, 'delivered');\\n      return;\\n    }\\n\\n    if (result.retryable && job.attempts \u003C 2) {\\n      await this.jobs.schedule(job.id, {\\n        status: 'retry_wait',\\n        channel: job.channel,\\n        attempts: job.attempts + 1,\\n        runAt: Date.now() + 1000 * 2 ** job.attempts\\n      });\\n      return;\\n    }\\n\\n    if (job.channel === 'email') {\\n      await this.jobs.schedule(job.id, {\\n        status: 'queued',\\n        channel: 'sms',\\n        attempts: 0,\\n        runAt: Date.now()\\n      });\\n      return;\\n    }\\n    await this.jobs.complete(job.id, 'failed');\\n  }\\n}\", \"state_transitions\": \"[{\\\"from_state\\\": \\\"queued or retry_wait\\\", \\\"to_state\\\": \\\"sending\\\", \\\"condition\\\": \\\"The job is due and claimDue successfully claims it.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"retry_wait\\\", \\\"condition\\\": \\\"The provider returns a retryable failure and attempts is less than two; the repository stores the incremented attempt count and future runAt.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"queued\\\", \\\"condition\\\": \\\"An email job has a non-retryable failure or has exhausted retries; it is scheduled immediately on SMS with attempts reset to zero.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"delivered\\\", \\\"condition\\\": \\\"The selected provider returns success and the repository completes the job as delivered.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"failed\\\", \\\"condition\\\": \\\"The SMS provider fails non-retryably or after its retry budget is exhausted.\\\"}]\", \"idempotency_analysis\": \"The repository's documented claimDue operation atomically claims a due job and moves it to sending, which can prevent two workers from processing the same eligible job concurrently if the repository honors that contract. The job ID serves as the claim identifier, but no provider-side idempotency key is passed. If a provider accepts a message and the worker crashes before complete or schedule is persisted, a later recovery may send it again; exactly-once delivery is not established by this code.\", \"control_flow_analysis\": \"{\\\"main_flow\\\": \\\"QueueWorker first asks the repository to claim the due job; if the claim fails, it does nothing. It sends through the job's current channel. Success completes the job as delivered. A retryable failure within the retry budget is persisted for a later attempt. Once that budget is exhausted, or after a non-retryable failure, an email job is queued immediately on SMS with its attempt count reset; a failing SMS job is completed as failed.\\\", \\\"branch_conditions\\\": [\\\"A false result from claimDue stops processing before a provider call.\\\", \\\"A successful provider result completes the job as delivered.\\\", \\\"A retryable result with attempts less than two schedules another attempt on the same channel.\\\", \\\"Retry scheduling uses a delay of 1,000 ms when attempts is zero and 2,000 ms when attempts is one.\\\", \\\"A non-retryable failure or a retryable failure at attempts two skips same-channel retrying.\\\", \\\"After same-channel retries stop, email switches to SMS immediately; SMS failure completes the job as failed.\\\"]}\", \"component_dependencies\": \"[{\\\"component_name\\\": \\\"QueueWorker\\\", \\\"responsibility\\\": \\\"Claims due jobs, invokes the selected provider, and chooses retry, fallback, or completion behavior.\\\", \\\"dependencies\\\": [\\\"JobRepository\\\", \\\"Provider\\\", \\\"Date.now\\\"]}, {\\\"component_name\\\": \\\"JobRepository\\\", \\\"responsibility\\\": \\\"Atomically claims eligible jobs, persists scheduled work, and records terminal status.\\\", \\\"dependencies\\\": []}, {\\\"component_name\\\": \\\"Provider\\\", \\\"responsibility\\\": \\\"Sends a job's recipient and payload through a particular channel and reports retryability on failure.\\\", \\\"dependencies\\\": []}]\", \"delivery_behavior_impact\": \"Persisted exponential backoff limits rapid repeat attempts and can absorb transient provider failures, while the email-to-SMS switch provides an alternate channel after email's retry budget is exhausted. The fallback resets the attempt count, giving SMS its own retry budget and potentially increasing eventual delivery at the cost of latency. Atomic job claiming limits concurrent processing, but a crash between provider acceptance and persistence can still cause duplicate delivery because provider-side idempotency is absent. Exceptions can also leave a claimed job without a recorded retry or terminal state.\", \"retry_and_fallback_analysis\": \"{\\\"retry_trigger\\\": \\\"Only a returned failure marked retryable triggers a same-channel retry, and only while the job's attempts value is less than two. Non-retryable results proceed directly to fallback or terminal failure. Thrown exceptions are not caught.\\\", \\\"retry_policy\\\": \\\"The worker allows up to two scheduled retries per channel, for three total attempts when the initial job has attempts zero. Backoff is exponential: 1,000 ms before the next attempt when attempts is zero, then 2,000 ms when it is one. Retry timing is persisted as runAt; execution of due jobs is outside this code.\\\", \\\"fallback_behavior\\\": \\\"After email fails permanently or exhausts its retry budget, the job is scheduled immediately on SMS with attempts reset to zero. SMS has the same retry policy, but there is no further fallback after SMS stops retrying; the job is marked failed.\\\"}\"}","文本","type Channel = 'email' | 'sms';\ntype JobStatus = 'queued' | 'retry_wait' | 'sending' | 'delivered' | 'failed';\ntype SendResult = { ok: true } | { ok: false; retryable: boolean };\n\ninterface DeliveryJob {\n  id: string;\n  channel: Channel;\n  attempts: number;\n  recipient: string;\n  payload: string;\n}\ninterface JobRepository {\n  \u002F\u002F Atomically claims a due queued or retry_wait job and moves it to sending.\n  claimDue(jobId: string): Promise\u003Cboolean>;\n  schedule(jobId: string, update: { status: 'retry_wait' | 'queued'; channel: Channel; attempts: number; runAt: number }): Promise\u003Cvoid>;\n  complete(jobId: string, status: 'delivered' | 'failed'): Promise\u003Cvoid>;\n}\ninterface Provider {\n  send(recipient: string, payload: string): Promise\u003CSendResult>;\n}\n\nclass QueueWorker {\n  constructor(private jobs: JobRepository, private providers: Record\u003CChannel, Provider>) {}\n\n  async process(job: DeliveryJob): Promise\u003Cvoid> {\n    if (!(await this.jobs.claimDue(job.id))) return;\n    const result = await this.providers[job.channel].send(job.recipient, job.payload);\n    if (result.ok) {\n      await this.jobs.complete(job.id, 'delivered');\n      return;\n    }\n\n    if (result.retryable && job.attempts \u003C 2) {\n      await this.jobs.schedule(job.id, {\n        status: 'retry_wait',\n        channel: job.channel,\n        attempts: job.attempts + 1,\n        runAt: Date.now() + 1000 * 2 ** job.attempts\n      });\n      return;\n    }\n\n    if (job.channel === 'email') {\n      await this.jobs.schedule(job.id, {\n        status: 'queued',\n        channel: 'sms',\n        attempts: 0,\n        runAt: Date.now()\n      });\n      return;\n    }\n    await this.jobs.complete(job.id, 'failed');\n  }\n}","[{\"from_state\": \"queued or retry_wait\", \"to_state\": \"sending\", \"condition\": \"The job is due and claimDue successfully claims it.\"}, {\"from_state\": \"sending\", \"to_state\": \"retry_wait\", \"condition\": \"The provider returns a retryable failure and attempts is less than two; the repository stores the incremented attempt count and future runAt.\"}, {\"from_state\": \"sending\", \"to_state\": \"queued\", \"condition\": \"An email job has a non-retryable failure or has exhausted retries; it is scheduled immediately on SMS with attempts reset to zero.\"}, {\"from_state\": \"sending\", \"to_state\": \"delivered\", \"condition\": \"The selected provider returns success and the repository completes the job as delivered.\"}, {\"from_state\": \"sending\", \"to_state\": \"failed\", \"condition\": \"The SMS provider fails non-retryably or after its retry budget is exhausted.\"}]","The repository's documented claimDue operation atomically claims a due job and moves it to sending, which can prevent two workers from processing the same eligible job concurrently if the repository honors that contract. The job ID serves as the claim identifier, but no provider-side idempotency key is passed. If a provider accepts a message and the worker crashes before complete or schedule is persisted, a later recovery may send it again; exactly-once delivery is not established by this code.","{\"main_flow\": \"QueueWorker first asks the repository to claim the due job; if the claim fails, it does nothing. It sends through the job's current channel. Success completes the job as delivered. A retryable failure within the retry budget is persisted for a later attempt. Once that budget is exhausted, or after a non-retryable failure, an email job is queued immediately on SMS with its attempt count reset; a failing SMS job is completed as failed.\", \"branch_conditions\": [\"A false result from claimDue stops processing before a provider call.\", \"A successful provider result completes the job as delivered.\", \"A retryable result with attempts less than two schedules another attempt on the same channel.\", \"Retry scheduling uses a delay of 1,000 ms when attempts is zero and 2,000 ms when attempts is one.\", \"A non-retryable failure or a retryable failure at attempts two skips same-channel retrying.\", \"After same-channel retries stop, email switches to SMS immediately; SMS failure completes the job as failed.\"]}","[{\"component_name\": \"QueueWorker\", \"responsibility\": \"Claims due jobs, invokes the selected provider, and chooses retry, fallback, or completion behavior.\", \"dependencies\": [\"JobRepository\", \"Provider\", \"Date.now\"]}, {\"component_name\": \"JobRepository\", \"responsibility\": \"Atomically claims eligible jobs, persists scheduled work, and records terminal status.\", \"dependencies\": []}, {\"component_name\": \"Provider\", \"responsibility\": \"Sends a job's recipient and payload through a particular channel and reports retryability on failure.\", \"dependencies\": []}]","Persisted exponential backoff limits rapid repeat attempts and can absorb transient provider failures, while the email-to-SMS switch provides an alternate channel after email's retry budget is exhausted. The fallback resets the attempt count, giving SMS its own retry budget and potentially increasing eventual delivery at the cost of latency. Atomic job claiming limits concurrent processing, but a crash between provider acceptance and persistence can still cause duplicate delivery because provider-side idempotency is absent. Exceptions can also leave a claimed job without a recorded retry or terminal state.","{\"retry_trigger\": \"Only a returned failure marked retryable triggers a same-channel retry, and only while the job's attempts value is less than two. Non-retryable results proceed directly to fallback or terminal failure. Thrown exceptions are not caught.\", \"retry_policy\": \"The worker allows up to two scheduled retries per channel, for three total attempts when the initial job has attempts zero. Backoff is exponential: 1,000 ms before the next attempt when attempts is zero, then 2,000 ms when it is one. Retry timing is persisted as runAt; execution of due jobs is outside this code.\", \"fallback_behavior\": \"After email fails permanently or exhausts its retry budget, the job is scheduled immediately on SMS with attempts reset to zero. SMS has the same retry policy, but there is no further fallback after SMS stops retrying; the job is marked failed.\"}",{"id":660,"relate_table":646,"relate_id":661,"file_size":573,"file_name":662,"path":8,"duration":573,"cate":483,"file_format":649,"audio_rate":8,"audio_channel":522,"audio_bit_depth":522,"quality":8,"annotation":663,"cate_name":651,"source_code":664,"state_transitions":665,"idempotency_analysis":666,"control_flow_analysis":667,"component_dependencies":668,"delivery_behavior_impact":669,"retry_and_fallback_analysis":670},14760,1004253610,"样例_2.json","{\"source_code\": \"type SendResult = { ok: true } | { ok: false; retryable: boolean };\\ntype ClaimResult = 'acquired' | 'delivered' | 'busy';\\ntype StoredStatus = 'delivered' | 'failed';\\n\\ninterface Provider {\\n  send(recipient: string, body: string): Promise\u003CSendResult>;\\n}\\ninterface IdempotencyStore {\\n  \u002F\u002F claim atomically reserves a key unless it is already delivered or in flight.\\n  claim(key: string): Promise\u003CClaimResult>;\\n  mark(key: string, status: StoredStatus): Promise\u003Cvoid>;\\n}\\ninterface Notice { key: string; recipient: string; body: string; route: string[]; }\\nconst sleep = (ms: number) => new Promise\u003Cvoid>(resolve => setTimeout(resolve, ms));\\n\\nclass RoutedSender {\\n  constructor(private providers: Record\u003Cstring, Provider>, private idempotency: IdempotencyStore) {}\\n\\n  async send(notice: Notice): Promise\u003Cstring> {\\n    const claim = await this.idempotency.claim(notice.key);\\n    if (claim !== 'acquired') return claim === 'delivered' ? 'delivered' : 'in_flight';\\n\\n    for (const channel of notice.route) {\\n      const provider = this.providers[channel];\\n      if (!provider) continue;\\n      for (let attempt = 1; attempt \u003C= 2; attempt++) {\\n        const result = await provider.send(notice.recipient, notice.body);\\n        if (result.ok) {\\n          await this.idempotency.mark(notice.key, 'delivered');\\n          return 'delivered';\\n        }\\n        if (!result.retryable) break;\\n        if (attempt \u003C 2) await sleep(250);\\n      }\\n    }\\n\\n    await this.idempotency.mark(notice.key, 'failed');\\n    return 'failed';\\n  }\\n}\", \"state_transitions\": \"[{\\\"from_state\\\": \\\"unclaimed\\\", \\\"to_state\\\": \\\"in_flight\\\", \\\"condition\\\": \\\"The store returns acquired from the atomic claim operation.\\\"}, {\\\"from_state\\\": \\\"in_flight\\\", \\\"to_state\\\": \\\"delivered\\\", \\\"condition\\\": \\\"Any provider on the ordered route succeeds and the sender records delivered.\\\"}, {\\\"from_state\\\": \\\"in_flight\\\", \\\"to_state\\\": \\\"failed\\\", \\\"condition\\\": \\\"All route entries are unavailable or their attempts fail, and the sender records failed.\\\"}]\", \"idempotency_analysis\": \"The sender relies on IdempotencyStore.claim to atomically distinguish acquired, delivered, and busy keys before any provider call. This prevents concurrent sends only if the store fulfills the documented atomic-claim contract. The key is not passed to providers, so provider-side deduplication is not shown. Exceptions after a claim are uncaught, and no claim release or recovery path appears in this code.\", \"control_flow_analysis\": \"{\\\"main_flow\\\": \\\"RoutedSender first atomically claims the notice key. It returns without sending if the key is already delivered or in flight. For an acquired key, it walks the requested route in order, skips channels without a configured provider, and makes up to two attempts per available provider. A successful send marks the key delivered and stops; exhausting the route marks it failed.\\\", \\\"branch_conditions\\\": [\\\"A delivered claim returns delivered, while a busy claim returns in_flight; neither invokes a provider.\\\", \\\"A route entry with no configured provider is skipped.\\\", \\\"A successful provider result marks the notice delivered and ends processing.\\\", \\\"A non-retryable failure moves directly to the next route entry.\\\", \\\"A retryable failure gets one retry after a 250 ms delay; after the second failed attempt, processing advances to the next route entry.\\\", \\\"If no route entry succeeds, the store is marked failed.\\\"]}\", \"component_dependencies\": \"[{\\\"component_name\\\": \\\"RoutedSender\\\", \\\"responsibility\\\": \\\"Claims the idempotency key and coordinates ordered channel attempts and status updates.\\\", \\\"dependencies\\\": [\\\"Provider\\\", \\\"IdempotencyStore\\\", \\\"sleep\\\"]}, {\\\"component_name\\\": \\\"Provider\\\", \\\"responsibility\\\": \\\"Sends a notice over a configured channel and reports success or whether a failure is retryable.\\\", \\\"dependencies\\\": []}, {\\\"component_name\\\": \\\"IdempotencyStore\\\", \\\"responsibility\\\": \\\"Atomically claims a notice key and records delivered or failed status.\\\", \\\"dependencies\\\": []}]\", \"delivery_behavior_impact\": \"Ordered routing makes channel preference explicit and allows later channels to recover from an unavailable or failing earlier channel. Limiting each channel to two attempts bounds per-channel delay, while the 250 ms retry can help with transient failures. A longer route can increase total latency. Atomic claiming reduces concurrent duplicate sends, but provider acceptance followed by a process failure before mark can still lead to a later redelivery if the store permits recovery; provider-side deduplication is not shown.\", \"retry_and_fallback_analysis\": \"{\\\"retry_trigger\\\": \\\"A provider result with ok false and retryable true triggers a retry on the same channel. Non-retryable failures advance immediately to the next route entry. Thrown exceptions are not caught.\\\", \\\"retry_policy\\\": \\\"Each configured provider receives at most two attempts. The only retry delay is 250 ms between those attempts. No further retry is made on that provider after the second failure; no persistent retry scheduling is shown.\\\", \\\"fallback_behavior\\\": \\\"The route array determines channel order. After a channel fails or is unconfigured, the sender proceeds to the next entry. It stops at the first successful provider. If all entries are unavailable or fail, it marks the notice failed. The code does not define a default route or select channels outside the supplied array.\\\"}\"}","type SendResult = { ok: true } | { ok: false; retryable: boolean };\ntype ClaimResult = 'acquired' | 'delivered' | 'busy';\ntype StoredStatus = 'delivered' | 'failed';\n\ninterface Provider {\n  send(recipient: string, body: string): Promise\u003CSendResult>;\n}\ninterface IdempotencyStore {\n  \u002F\u002F claim atomically reserves a key unless it is already delivered or in flight.\n  claim(key: string): Promise\u003CClaimResult>;\n  mark(key: string, status: StoredStatus): Promise\u003Cvoid>;\n}\ninterface Notice { key: string; recipient: string; body: string; route: string[]; }\nconst sleep = (ms: number) => new Promise\u003Cvoid>(resolve => setTimeout(resolve, ms));\n\nclass RoutedSender {\n  constructor(private providers: Record\u003Cstring, Provider>, private idempotency: IdempotencyStore) {}\n\n  async send(notice: Notice): Promise\u003Cstring> {\n    const claim = await this.idempotency.claim(notice.key);\n    if (claim !== 'acquired') return claim === 'delivered' ? 'delivered' : 'in_flight';\n\n    for (const channel of notice.route) {\n      const provider = this.providers[channel];\n      if (!provider) continue;\n      for (let attempt = 1; attempt \u003C= 2; attempt++) {\n        const result = await provider.send(notice.recipient, notice.body);\n        if (result.ok) {\n          await this.idempotency.mark(notice.key, 'delivered');\n          return 'delivered';\n        }\n        if (!result.retryable) break;\n        if (attempt \u003C 2) await sleep(250);\n      }\n    }\n\n    await this.idempotency.mark(notice.key, 'failed');\n    return 'failed';\n  }\n}","[{\"from_state\": \"unclaimed\", \"to_state\": \"in_flight\", \"condition\": \"The store returns acquired from the atomic claim operation.\"}, {\"from_state\": \"in_flight\", \"to_state\": \"delivered\", \"condition\": \"Any provider on the ordered route succeeds and the sender records delivered.\"}, {\"from_state\": \"in_flight\", \"to_state\": \"failed\", \"condition\": \"All route entries are unavailable or their attempts fail, and the sender records failed.\"}]","The sender relies on IdempotencyStore.claim to atomically distinguish acquired, delivered, and busy keys before any provider call. This prevents concurrent sends only if the store fulfills the documented atomic-claim contract. The key is not passed to providers, so provider-side deduplication is not shown. Exceptions after a claim are uncaught, and no claim release or recovery path appears in this code.","{\"main_flow\": \"RoutedSender first atomically claims the notice key. It returns without sending if the key is already delivered or in flight. For an acquired key, it walks the requested route in order, skips channels without a configured provider, and makes up to two attempts per available provider. A successful send marks the key delivered and stops; exhausting the route marks it failed.\", \"branch_conditions\": [\"A delivered claim returns delivered, while a busy claim returns in_flight; neither invokes a provider.\", \"A route entry with no configured provider is skipped.\", \"A successful provider result marks the notice delivered and ends processing.\", \"A non-retryable failure moves directly to the next route entry.\", \"A retryable failure gets one retry after a 250 ms delay; after the second failed attempt, processing advances to the next route entry.\", \"If no route entry succeeds, the store is marked failed.\"]}","[{\"component_name\": \"RoutedSender\", \"responsibility\": \"Claims the idempotency key and coordinates ordered channel attempts and status updates.\", \"dependencies\": [\"Provider\", \"IdempotencyStore\", \"sleep\"]}, {\"component_name\": \"Provider\", \"responsibility\": \"Sends a notice over a configured channel and reports success or whether a failure is retryable.\", \"dependencies\": []}, {\"component_name\": \"IdempotencyStore\", \"responsibility\": \"Atomically claims a notice key and records delivered or failed status.\", \"dependencies\": []}]","Ordered routing makes channel preference explicit and allows later channels to recover from an unavailable or failing earlier channel. Limiting each channel to two attempts bounds per-channel delay, while the 250 ms retry can help with transient failures. A longer route can increase total latency. Atomic claiming reduces concurrent duplicate sends, but provider acceptance followed by a process failure before mark can still lead to a later redelivery if the store permits recovery; provider-side deduplication is not shown.","{\"retry_trigger\": \"A provider result with ok false and retryable true triggers a retry on the same channel. Non-retryable failures advance immediately to the next route entry. Thrown exceptions are not caught.\", \"retry_policy\": \"Each configured provider receives at most two attempts. The only retry delay is 250 ms between those attempts. No further retry is made on that provider after the second failure; no persistent retry scheduling is shown.\", \"fallback_behavior\": \"The route array determines channel order. After a channel fails or is unconfigured, the sender proceeds to the next entry. It stops at the first successful provider. If all entries are unavailable or fail, it marks the notice failed. The code does not define a default route or select channels outside the supplied array.\"}",{"id":672,"relate_table":646,"relate_id":673,"file_size":573,"file_name":674,"path":8,"duration":573,"cate":483,"file_format":649,"audio_rate":8,"audio_channel":522,"audio_bit_depth":522,"quality":8,"annotation":675,"cate_name":651,"source_code":676,"state_transitions":677,"idempotency_analysis":678,"control_flow_analysis":679,"component_dependencies":680,"delivery_behavior_impact":681,"retry_and_fallback_analysis":682},14759,22955915,"样例_1.json","{\"source_code\": \"type DeliveryStatus = 'sending' | 'sent' | 'failed';\\ntype SendResult = { ok: true } | { ok: false; retryable: boolean; error: string };\\n\\ninterface Provider {\\n  send(recipient: string, body: string): Promise\u003CSendResult>;\\n}\\ninterface NotificationStore {\\n  getStatus(key: string): Promise\u003CDeliveryStatus | undefined>;\\n  setStatus(key: string, status: DeliveryStatus): Promise\u003Cvoid>;\\n}\\nconst delay = (ms: number) => new Promise\u003Cvoid>(resolve => setTimeout(resolve, ms));\\n\\nclass DeliveryService {\\n  constructor(private primary: Provider, private backup: Provider, private store: NotificationStore) {}\\n\\n  async deliver(key: string, recipient: string, body: string): Promise\u003CDeliveryStatus> {\\n    const current = await this.store.getStatus(key);\\n    if (current === 'sent' || current === 'sending') return current;\\n\\n    await this.store.setStatus(key, 'sending');\\n    for (let attempt = 1; attempt \u003C= 3; attempt++) {\\n      const result = await this.primary.send(recipient, body);\\n      if (result.ok) {\\n        await this.store.setStatus(key, 'sent');\\n        return 'sent';\\n      }\\n      if (!result.retryable) break;\\n      if (attempt \u003C 3) await delay(500 * 2 ** (attempt - 1));\\n    }\\n\\n    const fallback = await this.backup.send(recipient, body);\\n    const finalStatus: DeliveryStatus = fallback.ok ? 'sent' : 'failed';\\n    await this.store.setStatus(key, finalStatus);\\n    return finalStatus;\\n  }\\n}\", \"state_transitions\": \"[{\\\"from_state\\\": \\\"absent or failed\\\", \\\"to_state\\\": \\\"sending\\\", \\\"condition\\\": \\\"The stored status is neither sent nor sending, and delivery begins.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"sent\\\", \\\"condition\\\": \\\"The primary provider succeeds, or the backup provider succeeds.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"failed\\\", \\\"condition\\\": \\\"The primary attempts do not succeed and the backup attempt fails.\\\"}]\", \"idempotency_analysis\": \"The store status check suppresses a repeated call when the key is already sent or sending. However, the read and subsequent setStatus are separate operations, so concurrent callers can both pass the check; atomic claiming or a unique-key constraint is not shown. A crash after marking sending can leave the key in that status, which future calls return without recovery. No provider-side idempotency key is passed.\", \"control_flow_analysis\": \"{\\\"main_flow\\\": \\\"DeliveryService first reads the stored status and returns immediately for a notification already marked sent or sending. Otherwise it marks the notification sending, tries the primary provider up to three times, and records sent on success. A non-retryable failure or exhausted retry budget leads to one attempt through the backup provider; its result determines the final stored status.\\\", \\\"branch_conditions\\\": [\\\"If the stored status is sent or sending, no provider is called.\\\", \\\"A successful primary result records sent and ends delivery.\\\", \\\"A non-retryable primary failure exits the retry loop immediately.\\\", \\\"A retryable primary failure is retried while fewer than three attempts have been made; delays before the second and third attempts are 500 ms and 1,000 ms.\\\", \\\"After the primary loop exits, the backup is called once; its success records sent and its failure records failed.\\\"]}\", \"component_dependencies\": \"[{\\\"component_name\\\": \\\"DeliveryService\\\", \\\"responsibility\\\": \\\"Coordinates status checks, primary-channel retries, backup-channel delivery, and final status updates.\\\", \\\"dependencies\\\": [\\\"Provider\\\", \\\"NotificationStore\\\", \\\"delay\\\"]}, {\\\"component_name\\\": \\\"Provider\\\", \\\"responsibility\\\": \\\"Sends a notification and returns a success result or a failure with a retryability flag.\\\", \\\"dependencies\\\": []}, {\\\"component_name\\\": \\\"NotificationStore\\\", \\\"responsibility\\\": \\\"Reads and writes the notification delivery status.\\\", \\\"dependencies\\\": []}]\", \"delivery_behavior_impact\": \"The three-attempt primary loop can improve delivery when failures are transient, at the cost of added latency from its two backoff delays. A permanent primary failure avoids unnecessary primary retries but still incurs one backup attempt. Because the status check and write are not atomic and no provider idempotency key is used, concurrent calls or a crash around provider acceptance can still produce duplicate delivery. Uncaught provider exceptions can exit before a final status is recorded.\", \"retry_and_fallback_analysis\": \"{\\\"retry_trigger\\\": \\\"Only a primary-provider result with ok false and retryable true triggers another primary attempt. A non-retryable result skips remaining primary attempts and proceeds to the backup. Thrown exceptions are not caught in this code.\\\", \\\"retry_policy\\\": \\\"The primary is called at most three times. Delays are 500 ms and 1,000 ms before attempts two and three, respectively. There is no delay between the final primary attempt and the backup. The backup is attempted once, with no retry policy shown.\\\", \\\"fallback_behavior\\\": \\\"The backup provider is called after a non-retryable primary failure or after all three primary attempts fail. The code has one configured backup and does not show channel selection beyond that. Backup success records sent; backup failure records failed.\\\"}\"}","type DeliveryStatus = 'sending' | 'sent' | 'failed';\ntype SendResult = { ok: true } | { ok: false; retryable: boolean; error: string };\n\ninterface Provider {\n  send(recipient: string, body: string): Promise\u003CSendResult>;\n}\ninterface NotificationStore {\n  getStatus(key: string): Promise\u003CDeliveryStatus | undefined>;\n  setStatus(key: string, status: DeliveryStatus): Promise\u003Cvoid>;\n}\nconst delay = (ms: number) => new Promise\u003Cvoid>(resolve => setTimeout(resolve, ms));\n\nclass DeliveryService {\n  constructor(private primary: Provider, private backup: Provider, private store: NotificationStore) {}\n\n  async deliver(key: string, recipient: string, body: string): Promise\u003CDeliveryStatus> {\n    const current = await this.store.getStatus(key);\n    if (current === 'sent' || current === 'sending') return current;\n\n    await this.store.setStatus(key, 'sending');\n    for (let attempt = 1; attempt \u003C= 3; attempt++) {\n      const result = await this.primary.send(recipient, body);\n      if (result.ok) {\n        await this.store.setStatus(key, 'sent');\n        return 'sent';\n      }\n      if (!result.retryable) break;\n      if (attempt \u003C 3) await delay(500 * 2 ** (attempt - 1));\n    }\n\n    const fallback = await this.backup.send(recipient, body);\n    const finalStatus: DeliveryStatus = fallback.ok ? 'sent' : 'failed';\n    await this.store.setStatus(key, finalStatus);\n    return finalStatus;\n  }\n}","[{\"from_state\": \"absent or failed\", \"to_state\": \"sending\", \"condition\": \"The stored status is neither sent nor sending, and delivery begins.\"}, {\"from_state\": \"sending\", \"to_state\": \"sent\", \"condition\": \"The primary provider succeeds, or the backup provider succeeds.\"}, {\"from_state\": \"sending\", \"to_state\": \"failed\", \"condition\": \"The primary attempts do not succeed and the backup attempt fails.\"}]","The store status check suppresses a repeated call when the key is already sent or sending. However, the read and subsequent setStatus are separate operations, so concurrent callers can both pass the check; atomic claiming or a unique-key constraint is not shown. A crash after marking sending can leave the key in that status, which future calls return without recovery. No provider-side idempotency key is passed.","{\"main_flow\": \"DeliveryService first reads the stored status and returns immediately for a notification already marked sent or sending. Otherwise it marks the notification sending, tries the primary provider up to three times, and records sent on success. A non-retryable failure or exhausted retry budget leads to one attempt through the backup provider; its result determines the final stored status.\", \"branch_conditions\": [\"If the stored status is sent or sending, no provider is called.\", \"A successful primary result records sent and ends delivery.\", \"A non-retryable primary failure exits the retry loop immediately.\", \"A retryable primary failure is retried while fewer than three attempts have been made; delays before the second and third attempts are 500 ms and 1,000 ms.\", \"After the primary loop exits, the backup is called once; its success records sent and its failure records failed.\"]}","[{\"component_name\": \"DeliveryService\", \"responsibility\": \"Coordinates status checks, primary-channel retries, backup-channel delivery, and final status updates.\", \"dependencies\": [\"Provider\", \"NotificationStore\", \"delay\"]}, {\"component_name\": \"Provider\", \"responsibility\": \"Sends a notification and returns a success result or a failure with a retryability flag.\", \"dependencies\": []}, {\"component_name\": \"NotificationStore\", \"responsibility\": \"Reads and writes the notification delivery status.\", \"dependencies\": []}]","The three-attempt primary loop can improve delivery when failures are transient, at the cost of added latency from its two backoff delays. A permanent primary failure avoids unnecessary primary retries but still incurs one backup attempt. Because the status check and write are not atomic and no provider idempotency key is used, concurrent calls or a crash around provider acceptance can still produce duplicate delivery. Uncaught provider exceptions can exit before a final status is recorded.","{\"retry_trigger\": \"Only a primary-provider result with ok false and retryable true triggers another primary attempt. A non-retryable result skips remaining primary attempts and proceeds to the backup. Thrown exceptions are not caught in this code.\", \"retry_policy\": \"The primary is called at most three times. Delays are 500 ms and 1,000 ms before attempts two and three, respectively. There is no delay between the final primary attempt and the backup. The backup is attempted once, with no retry policy shown.\", \"fallback_behavior\": \"The backup provider is called after a non-retryable primary failure or after all three primary attempts fail. The code has one configured backup and does not show channel selection beyond that. Backup success records sent; backup failure records failed.\"}","{\"source_code\":\"type Channel = 'email' | 'sms';\\ntype JobStatus = 'queued' | 'retry_wait' | 'sending' | 'delivered' | 'failed';\\ntype SendResult = { ok: true } | { ok: false; retryable: boolean };\\n\\ninterface DeliveryJob {\\n  id: string;\\n  channel: Channel;\\n  attempts: number;\\n  recipient: string;\\n  payload: string;\\n}\\ninterface JobRepository {\\n  \\\u002F\\\u002F Atomically claims a due queued or retry_wait job and moves it to sending.\\n  claimDue(jobId: string): Promise\u003Cboolean>;\\n  schedule(jobId: string, update: { status: 'retry_wait' | 'queued'; channel: Channel; attempts: number; runAt: number }): Promise\u003Cvoid>;\\n  complete(jobId: string, status: 'delivered' | 'failed'): Promise\u003Cvoid>;\\n}\\ninterface Provider {\\n  send(recipient: string, payload: string): Promise\u003CSendResult>;\\n}\\n\\nclass QueueWorker {\\n  constructor(private jobs: JobRepository, private providers: Record\u003CChannel, Provider>) {}\\n\\n  async process(job: DeliveryJob): Promise\u003Cvoid> {\\n    if (!(await this.jobs.claimDue(job.id))) return;\\n    const result = await this.providers[job.channel].send(job.recipient, job.payload);\\n    if (result.ok) {\\n      await this.jobs.complete(job.id, 'delivered');\\n      return;\\n    }\\n\\n    if (result.retryable && job.attempts \u003C 2) {\\n      await this.jobs.schedule(job.id, {\\n        status: 'retry_wait',\\n        channel: job.channel,\\n        attempts: job.attempts + 1,\\n        runAt: Date.now() + 1000 * 2 ** job.attempts\\n      });\\n      return;\\n    }\\n\\n    if (job.channel === 'email') {\\n      await this.jobs.schedule(job.id, {\\n        status: 'queued',\\n        channel: 'sms',\\n        attempts: 0,\\n        runAt: Date.now()\\n      });\\n      return;\\n    }\\n    await this.jobs.complete(job.id, 'failed');\\n  }\\n}\",\"state_transitions\":\"[{\\\"from_state\\\": \\\"queued or retry_wait\\\", \\\"to_state\\\": \\\"sending\\\", \\\"condition\\\": \\\"The job is due and claimDue successfully claims it.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"retry_wait\\\", \\\"condition\\\": \\\"The provider returns a retryable failure and attempts is less than two; the repository stores the incremented attempt count and future runAt.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"queued\\\", \\\"condition\\\": \\\"An email job has a non-retryable failure or has exhausted retries; it is scheduled immediately on SMS with attempts reset to zero.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"delivered\\\", \\\"condition\\\": \\\"The selected provider returns success and the repository completes the job as delivered.\\\"}, {\\\"from_state\\\": \\\"sending\\\", \\\"to_state\\\": \\\"failed\\\", \\\"condition\\\": \\\"The SMS provider fails non-retryably or after its retry budget is exhausted.\\\"}]\",\"idempotency_analysis\":\"The repository's documented claimDue operation atomically claims a due job and moves it to sending, which can prevent two workers from processing the same eligible job concurrently if the repository honors that contract. The job ID serves as the claim identifier, but no provider-side idempotency key is passed. If a provider accepts a message and the worker crashes before complete or schedule is persisted, a later recovery may send it again; exactly-once delivery is not established by this code.\",\"control_flow_analysis\":\"{\\\"main_flow\\\": \\\"QueueWorker first asks the repository to claim the due job; if the claim fails, it does nothing. It sends through the job's current channel. Success completes the job as delivered. A retryable failure within the retry budget is persisted for a later attempt. Once that budget is exhausted, or after a non-retryable failure, an email job is queued immediately on SMS with its attempt count reset; a failing SMS job is completed as failed.\\\", \\\"branch_conditions\\\": [\\\"A false result from claimDue stops processing before a provider call.\\\", \\\"A successful provider result completes the job as delivered.\\\", \\\"A retryable result with attempts less than two schedules another attempt on the same channel.\\\", \\\"Retry scheduling uses a delay of 1,000 ms when attempts is zero and 2,000 ms when attempts is one.\\\", \\\"A non-retryable failure or a retryable failure at attempts two skips same-channel retrying.\\\", \\\"After same-channel retries stop, email switches to SMS immediately; SMS failure completes the job as failed.\\\"]}\",\"component_dependencies\":\"[{\\\"component_name\\\": \\\"QueueWorker\\\", \\\"responsibility\\\": \\\"Claims due jobs, invokes the selected provider, and chooses retry, fallback, or completion behavior.\\\", \\\"dependencies\\\": [\\\"JobRepository\\\", \\\"Provider\\\", \\\"Date.now\\\"]}, {\\\"component_name\\\": \\\"JobRepository\\\", \\\"responsibility\\\": \\\"Atomically claims eligible jobs, persists scheduled work, and records terminal status.\\\", \\\"dependencies\\\": []}, {\\\"component_name\\\": \\\"Provider\\\", \\\"responsibility\\\": \\\"Sends a job's recipient and payload through a particular channel and reports retryability on failure.\\\", \\\"dependencies\\\": []}]\",\"delivery_behavior_impact\":\"Persisted exponential backoff limits rapid repeat attempts and can absorb transient provider failures, while the email-to-SMS switch provides an alternate channel after email's retry budget is exhausted. The fallback resets the attempt count, giving SMS its own retry budget and potentially increasing eventual delivery at the cost of latency. Atomic job claiming limits concurrent processing, but a crash between provider acceptance and persistence can still cause duplicate delivery because provider-side idempotency is absent. Exceptions can also leave a claimed job without a recorded retry or terminal state.\",\"retry_and_fallback_analysis\":\"{\\\"retry_trigger\\\": \\\"Only a returned failure marked retryable triggers a same-channel retry, and only while the job's attempts value is less than two. Non-retryable results proceed directly to fallback or terminal failure. Thrown exceptions are not caught.\\\", \\\"retry_policy\\\": \\\"The worker allows up to two scheduled retries per channel, for three total attempts when the initial job has attempts zero. Backoff is exponential: 1,000 ms before the next attempt when attempts is zero, then 2,000 ms when it is one. Retry timing is persisted as runAt; execution of due jobs is outside this code.\\\", \\\"fallback_behavior\\\": \\\"After email fails permanently or exhausts its retry budget, the job is scheduled immediately on SMS with attempts reset to zero. SMS has the same retry policy, but there is no further fallback after SMS stops retrying; the job is marked failed.\\\"}\"}","MOBIUSI INC","https:\u002F\u002Fstatic.mobiusi.com\u002Fmobiwusi\u002F20250829\u002F7bf4ac62b4533e2b809998a6f1c5491e.png?Expires=1792463130&OSSAccessKeyId=LTAI5tH8MQqhgeiAtrzCHrxM&Signature=v6Tr8jBrdm4s5wU1SnnyGsYg%2Bhw%3D&x-oss-process=image%2Fresize%2Cm_fill%2Cw_35%2Ch_35",[687,693],{"type":688,"title":689,"count_data":690},"bar","Length distribution",[691],{"name":692,"value":483},"1k lower",{"type":694,"title":695,"count_data":696},"pie","Language distribution",[697],{"name":698,"value":483},"English"]