Sounds like you're using "Exit Rule." Lots of people seem to think this does something that it doesn't. What it does do is stop running additional actions/steps in your rule; what it doesn't do is un-schedule anything that may have been scheduled or "subscribed" to by previous actions: delays/delayed actions, waits, etc. To cancel a delay, you need to set the "Cancel?" flag on your delay or delayed action (there are subtle differences between the two, but that's another story and generally inconsequential if there is nothing after it), and then you need a "Cancel Delayed Actions" action somewhere to actually do it. (You'll see some people use the "Cancel Rule Timers" action here, which will cancel any delay with or without "Cancel?"/"cancelable" set on it. This also does a lot more, and I would not recommend using it unless you know what it entails; people presumably arrived at this by trial and error, not by reading the documentation.)
The Rule 4.0 docs (forum thread or official wiki docs--about the same but the inline screenshots on the forum are probably easier to read) are something I'd recommend reading. Some parts of them are geared towards Rule 3.0 readers and show how to upgrade or re-think rules, but you can ignore the previous-version comments and just see examples of how to do things in 4.0. While it's a different outcome, in your case, I think the motion lighting examples with cancelable delays would be a good place to start. You want almost the same thing, except you want a trigger for "lock changed" instead of "motion changed," an IF that checks for lock state instead of motion sensor state, and actions that either lock the lock after a delay (say, under "IF unlocked...") or cancel that delay (say, under "ELSE") instead of turning on/off lights--different devices, events, and actions, but it just shows you the most common paradigm in RM for delays and cancellations.
Hope this helps!
