This semaphore acquire covers the entire bridge_asset call, including the confirmation polling loop (up to 12 × 5s = 60s in production). That means an approve-resume holds the sole permit for up to a minute, blocking any concurrent pair submission. The redeem path at line 557 uses a narrower pattern, it acquires the semaphore only around deliver and releases it before polling. Would it make sense to apply the same pattern here, or is serializing through confirmation intentional? Either way a short comment would help clarify.
Originally posted by @shahnami in #319 (comment)
This semaphore acquire covers the entire
bridge_assetcall, including the confirmation polling loop (up to 12 × 5s = 60s in production). That means an approve-resume holds the sole permit for up to a minute, blocking any concurrent pair submission. The redeem path at line 557 uses a narrower pattern, it acquires the semaphore only arounddeliverand releases it before polling. Would it make sense to apply the same pattern here, or is serializing through confirmation intentional? Either way a short comment would help clarify.Originally posted by @shahnami in #319 (comment)