前端【免费下载链接】urqlThe highly customizable and versatile GraphQL client with which you add on features like normalized caching as you grow.项目地址https://gitcode.com/gh_mirrors/ur/urql点击查看免费下载urql/exchange-retry是 urql GraphQL 客户端中负责操作重试的标准扩展它以 exchange 工厂的形式让查询、变更和订阅在网络错误或指定错误条件下按可配置的策略自动重试。本文以该包的 CHANGELOG.md 记录的完整演进脉络为骨架结合 retryExchange 源码、官方使用文档 与 测试用例系统讲解安装配置、全部选项的默认值与语义、指数退避的内部实现、retryIf/retryWith的判定逻辑以及成功重置、teardown 中止等关键行为。读完本文你将能独立完成重试策略的选型、配置与故障排查并理解每个选项在源码层面的真实影响。retryExchange 是什么定位与安装retryExchange由urql/exchange-retry包导出入口见 exchanges/retry/src/index.ts仅导出工厂函数retryExchange及其选项类型RetryExchangeOptions。在 urql 的 exchange 管线中它被设计为捕获失败结果并重新投递的一环默认情况下它只对携带networkError的结果触发重试其余错误会原样放行见 retryExchange.ts 的判定逻辑。安装该包需要与urql本体并列进行yarn add urql/exchange-retry # 或 npm install --save urql/exchange-retry从 package.json 可以看到当前版本2.0.0将urql/core^6.0.0同时声明为 peer dependency 与普通依赖并依赖wonka^6.3.2作为流处理基础发布配置启用了 npm provenance对应 CHANGELOG 1.1.1 条目的Publish with npm provenance。快速上手在 Client 中接入把retryExchange加入 Client 的exchanges数组即可生效。官方文档给出的最简配置如下docs/advanced/retry-operations.mdimport { Client, cacheExchange, fetchExchange } from urql; import { retryExchange } from urql/exchange-retry; // 以下全部为默认值均可省略 const options { initialDelayMs: 1000, maxDelayMs: 15000, randomDelay: true, maxNumberAttempts: 2, retryIf: err err err.networkError, }; const client new Client({ url: http://localhost:1234/graphql, exchanges: [ cacheExchange, retryExchange(options), // 注意放置顺序 fetchExchange, ], });放置顺序至关重要retryExchange必须放在cacheExchange之后、fetchExchange之前。这样重试只会在操作已经过缓存、真正发起网络请求失败之后才被触发同时它拦截的是 fetch 返回的错误结果而不是缓存命中结果。官方文档对此的说明是We want to place theretryExchangebefore thefetchExchangeso that retries are only performedafterthe operation has passed through the cache and has attempted to fetchdocs/advanced/retry-operations.md。仓库中的可运行示例 examples/with-retry 展示了完整接入其 App.jsx 使用trygql的间歇性失败 schema随机抛出NO_SOUP错误配置了maxNumberAttempts: 10、maxDelayMs: 500并用retryIf匹配特定错误码。选项详解默认值、语义与源码依据RetryExchangeOptions的完整定义见 retryExchange.ts每个字段都带有 TSDoc 注释该包从 1.1.0 起为所有 exchange 添加 TSDoc见 CHANGELOG。默认值在工厂函数入口处统一解析retryExchange.ts。选项类型默认值语义initialDelayMsnumber1_000首次失败后等待的最小毫秒数即重试延迟的起点maxDelayMsnumber15_000延迟增长的上限防止对无法响应的服务器高频轰炸randomDelaybooleantrue是否启用随机指数退避为false时每次重试按initialDelayMs线性递增maxNumberAttemptsnumber2总尝试次数包含初始请求2即失败后重试 1 次retryIf(error, operation) booleanerr !!err.networkError决定某个错误结果是否值得重试返回false则放行不重试retryWith(error, operation) Operation \| null \| undefined无转换重试时的操作如切换 URL返回 nullish 表示不重试与retryIf同时存在时retryIf优先几个关键语义点值得展开maxNumberAttempts包含初始请求。官方文档明确指出2means one retry after the initial attempt并提示若想无限重试可直接传Number.POSITIVE_INFINITYdocs/advanced/retry-operations.md。源码中判断为((retry retry.count) || 0) MAX_ATTEMPTS - 1retryExchange.ts即达到上限前最后一次尝试会被放行给retryIf之外的下游同时通过dispatchDebug发出retryExhausted事件。retryIf接收第二个参数Operation。该能力是 0.2.0 版本新增的CHANGELOG #1117目的是让用户能针对特定类型的操作如 mutation、subscription主动跳过重试。测试用例也验证了retryIf会同时收到错误对象与操作对象retryExchange.test.ts。retryWith是retryIf的增强替代。当两者都未定义时默认只重试networkError定义了retryIf则以retryIf为准并覆盖retryWith只定义retryWith时返回 Operation 则用新操作重试返回 nullish 则放弃重试见源码 retryExchange.ts 与 TSDoc。options参数本身可选。1.3.2 版本将retryExchange()的参数标记为可选CHANGELOG #3775工厂签名因此是(options: RetryExchangeOptions {})retryExchange.ts不传任何选项也能直接使用。重试判定retryIf 与不同错误的应对retryIf让你精确控制什么错误值得重试。官方文档的进阶示例是同时匹配graphQLErrors与networkErrordocs/advanced/retry-operations.mdconst client new Client({ url: http://localhost:1234/graphql, exchanges: [ cacheExchange, retryExchange({ retryIf: error { return !!(error.graphQLErrors.length 0 || error.networkError); }, }), fetchExchange, ], });更细粒度的做法是检查graphQLErrors中的具体错误。示例 examples/with-retry/src/App.jsx 中通过error.graphQLErrors.some(x x.extensions?.code NO_SOUP)只对携带特定扩展错误码的查询重试其余错误如语法错误、权限问题则原样交给 UI 处理——这正是retryIf的价值避免对必然失败的请求反复重试。无retryIf时的兜底行为有专门的测试覆盖即使retryIf为undefined只要错误携带networkError就仍然会重试retryExchange.test.ts与默认值(error) !!error.networkError的行为一致。retryWith客户端 Failover 与回退retryWith是 0.3.0 版本引入的能力CHANGELOG #1881核心用途是在重试时替换操作本身实现客户端侧的主备切换。官方文档的 Failover 示例docs/advanced/retry-operations.mdconst fallbackUrl http://localhost:1337/anotherGraphql; const options { initialDelayMs: 1000, maxDelayMs: 15000, randomDelay: true, maxNumberAttempts: 2, retryWith: (error, operation) { if (error.networkError) { const context { ...operation.context, url: fallbackUrl }; return { ...operation, context }; } return null; }, };这里的模式是主 GraphQL 端点或某个 provider 的域名不可用时把操作的context.url替换为备用端点后重新投递若错误不满足条件则返回null放弃重试。该能力同样适用于 GraphQL 层错误场景例如接口按窗口灰度部署时新旧版本分别位于 URL X 与 URL Y。文档同时提醒retryWith是故障回退手段不具备负载均衡能力docs/advanced/retry-operations.md。源码中retryWith的结果会先经makeOperation重建保留operation.kind与扩展后的context再进入延迟队列retryExchange.ts。测试验证了两条路径返回 nullish 时重试被完全跳过下游只收到一次结果retryExchange.test.ts返回新操作时context中的自定义字段如counter会逐次递增并被下游观察到retryExchange.test.ts。退避算法内部实现从源码看延迟如何增长延迟计算位于 retryExchange.ts核心逻辑如下从operation.context.retry读取上一次的重试状态count与delay首次失败时初始化为{ count: 0, delay: null }retryCount自增delayAmount取上一次的delay或MIN_DELAY启用randomDelay默认时backoffFactor Math.random() 1.5若delayAmount * backoffFactor MAX_DELAY则按该随机因子放大延迟否则直接封顶为MAX_DELAY——随机化是为了避免惊群效应thundering herd即大量客户端同时失败后在同一时刻重试压垮服务器禁用randomDelay时delayAmount Math.min(retryCount * MIN_DELAY, MAX_DELAY)即按初始延迟线性递增首次失败等 1 秒第二次等 2 秒依此类推仍受maxDelayMs封顶新的delay写回retry状态并随makeOperation传入下一个上下文随后经debounce(() delayAmount)延时后投递。测试 retryExchange.test.ts 精确验证了固定延迟模式设置initialDelayMs: 50后每次重试的等待时间恰好为i * initialDelayMs第 1 次等 50ms、第 2 次等 100ms……与源码的线性公式一一对应。值得注意的是CHANGELOG 记录了两处与该算法直接相关的修复1.2.1 修复了延迟未随重试次数增加而增长的问题#34781.0.0 修复了randomDelay计算错误#2615。1.1.0 则配合urql/core的composeExchanges移除了冗余的share调用#3082。重试状态与成功重置context.retry 的生命周期每次重试的计数与延迟都存放在operation.context.retry中因此状态天然跟随操作传播且同一 client 上的多个并发操作互不干扰——测试用例retries if it hits an error and works for multiple concurrent operations专门验证了两个并发查询各自独立重试retryExchange.test.ts。1.2.0 版本引入了一个容易被忽视但很重要的行为一旦操作成功返回结果立即重置retry.count与retry.delayCHANGELOG #3229。源码在放行结果的filter分支里执行重置retryExchange.tsif (retry) { retry.count 0; retry.delay null; }这一重置对订阅subscription场景尤为关键订阅可能长时间运行、期间间歇性失败如果不重置计数旧的重试次数与延迟会一直被带在身上导致后续重试永远顶着最大延迟甚至被maxNumberAttempts提前掐断。对应的测试should reset the retry counter if an operation succeeded firstretryExchange.test.ts验证了失败→成功→再次失败的完整链路中第二次失败时context.retry已恢复为{ count: 0, delay: null }。示例 examples/with-retry/src/Color.jsx 展示了如何从结果侧读取重试信息展示给用户result.operation.context.retryCount。停止重试teardown、maxNumberAttempts 与防自我重试除了次数上限重试还有一条重要的刹车机制teardown 中止。源码构造了teardown$流监听同 key 的query说明操作被重新触发或teardown操作被取消事件并用takeUntil(teardown$)在延迟期间随时掐断待重试的操作retryExchange.ts。注释明确解释了原因如果操作自己又发起了一次新请求说明查询本身正在自我重试此时不应再叠加一层退避延迟。当重试次数耗尽时源码会发出retryExhausted调试事件并放行最终结果retryExchange.ts错误因此能正常流向 UI。调试事件在 DevTools 中观察重试过程从 0.1.5 版本起各 exchange 会派发调试事件供开发者工具展示CHANGELOG #608即 urql 的 Chrome/Firefox 扩展。retryExchange目前派发两类事件retryExchange.tsretryAttempt操作失败、重试被触发时携带retryCount与delayAmount本次等待毫秒数数据retryExhausted达到最大尝试次数、放弃继续重试时。这两类事件配合 0.1.7 加入的source调试名CHANGELOG #780可以明确区分事件由哪个 exchange 派发在排查为什么没重试/为什么一直重试时非常有价值。版本演进时间线CHANGELOG 中的关键里程碑CHANGELOG.md 完整记录了该包从v0.1.0初始发布到2.0.0的全部演进其中对使用行为有实质影响的里程碑如下版本类型实质变更0.2.0MinorretryIf增加第二个Operation参数可按操作类型决定是否重试0.3.0Minor新增retryWith选项支持重试时替换操作如切换 URL0.3.1Patch修复因setTimeout时序导致的应重试却未执行问题0.3.2Patchgraphqlpeer dependency 范围扩展至^16.0.0升级多包后建议npm dedupe0.3.3Patch顶层导出RetryExchangeOption类型1.0.0Major移除 IE11 支持不再保证 ES5 兼容、升级 Wonka v6、TypeScript 全量迁移、修复randomDelay1.1.0Minor移除冗余share调用由composeExchanges自动处理、补充全部 exchange 的 TSDoc1.1.1Patch发布启用 npm provenance1.2.0Minor成功结果到达后重置重试计数与延迟帮助订阅场景恢复1.2.1Patch修复延迟不随重试次数增长的 bug1.3.0Minorurql/core同时声明为 peer dependency 与普通依赖1.3.1Patch发布包移除 minified 文件及 sourcemap 的sourcesContent1.3.2PatchretryExchange()的 options 参数改为可选2.0.0Patch依赖升级至urql/core6.0.0从结构上看该包的功能面在 1.0.0 之前0.2.0 / 0.3.0就已定型1.x 之后主要是依赖治理peer dep、provenance、TSDoc与行为修复延迟计算、状态重置这为评估升级风险提供了依据2.0.0 之前没有破坏性 API 变更主要兼容性约束来自urql/core的大版本升级。实践建议默认配置只覆盖网络错误retryIf不配置时只有networkError会触发重试GraphQL 层错误如NO_SOUP这类业务错误码需要显式配置retryIf才重试。重试次数含初始请求maxNumberAttempts: 2实际只重试 1 次需要更宽松的策略如示例中的 10 次或无限重试Number.POSITIVE_INFINITY请按需设置。保持randomDelay: true默认随机指数退避能避免多客户端同时重试的惊群效应关闭后会退化为线性递增仍受maxDelayMs封顶。订阅场景依赖状态重置1.2.0 起的成功重置机制是订阅恢复能力的前提升级时不应回退到更早版本。retryWith用于 failover而非负载均衡切换 URL 或重写操作上下文是它的正确姿势分发流量不是它的职责。排障优先看调试事件retryAttempt与retryExhausted会给出每次重试的计数与等待时长配合source字段可快速定位重试链路问题。赞分享前端【免费下载链接】urqlThe highly customizable and versatile GraphQL client with which you add on features like normalized caching as you grow.项目地址https://gitcode.com/gh_mirrors/ur/urql点击查看免费下载相关推荐urql retryExchange 完全指南urql/exchange-retry 的重试策略、指数退避与故障转移实践urql retryExchange 完全指南urql/exchange retry 的重试策略、指数退避与故障转移实践 本文是 urql GraphQL前端WiFi感知革命RuView边缘AI人体姿态估计实战指南WiFi感知革命RuView边缘AI人体姿态估计实战指南 在当今智能感知领域一个颠覆性的技术正在悄然改变游戏规则——RuView WiFi感知系统。这个开源人工智能计算机视觉物联网智能家居后端嵌入式OpenCloud 重试机制基石深入解析 cenkalti/backoff v1 指数退避算法OpenCloud 重试机制基石深入解析 cenkalti/backoff v1 指数退避算法 指数退避Exponential Backoff是分布式系统后端微服务存储认证鉴权上一篇FlutterFire多项目管理终极指南在单个应用中轻松配置多个Firebase项目下一篇Terser专利技术压缩算法中的创新点解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
