We've seen a BF around index builds recently (linked) where the root cause came down to the index builds coordinator acquiring an Intent::LocalWrite when it should have acquired Intent::Write.

A problem with a write code path that is shared on primaries and secondaries is that it's not clear what intent should be registered. On a primary, Write should be taken. On a secondary, LocalWrite should be taken.

Blindly taking a Write intent on the code path will error on secondary oplog application. Blindly taking a LocalWrite on a the code path will mean that the write will not synchronize with step down (step down waits only for Write intent operations to drain).

As a result, currently some sort of conditional is required instead. In the index builds coordinator, we are using canDeclareIntent(), which returns false when the node is stepping down, but still a primary. This can cause a node to take LocalWrite and potentially write an oplog entry after becoming a secondary. A solution where we use the state of the node to make a decision may work, but needs confirming.

More importantly, having to make a decision on what intent means we're adding complexity - earlier both the code paths could blindly take the RSTL in IX mode without caring about what state the node was in. However, now we can't do that anymore and need to carefully consider which intent to take based on the state. We should try to come up with a good model to remove this complexity.