fix(Relayer): exclusivityDeadline is inclusive not exclusive

[nicholaspai]

No description provided.

[pxrl]

I am fwiw curious about how simulation works here, since if exclusivityDeadline === currentTime then you'd expect that by the time our transaction is simulated & submitted, the exclusivityDeadline should be in the past.

So I'm wondering whether we're seeing some quirk of simulation here, where the block timestamp used in simulation is from the previous block. I have to admit that I'm generally a bit vague about exactly what chain state is used when we are simulating.

In the worst case, this change might cause us to be slower to make fills with lapsed exclusivity, or given current SpokePool implementation, all fills (i.e. it might implicitly impose a 1 block confirmation delay). This would be especially noticeable where the destination chain has long block-ish times - i.e. mainnet, Linea, Scroll.

[pxrl]

Here's an example of something we might consider: #2027

We could alternatively consider adding "NotExclusiveRelayer" to the set of "acceptable failure" cases and suppress the simulation error, as we to for "RelayFilled" errors. The "NotExclusiveRelayer" scenario isn't triggering as frequently as it was before the SpokePool upgrade and associated config tweaks, so I think any adjustment here is now mostly about making the logs a bit quieter.

[nicholaspai]

What do you recommend we do?

[nicholaspai]

however, I still think this PR is correct and it shouldn't really delay deposits that much. How often are we finding an exclusivityDeadline exactly equal to currentTime? Seems like it'd be small

[nicholaspai]

3518ff7

[james-a-morris]

My gut feel is that this is a relatively small edge case given how unlikely it would be to be in this situation. LGTM good catch