Bugzilla – Bug 9243
Subscribers should not be notified of requests that occur before they subscribe
Last modified: 2009-03-26 12:30:05 UTC
If you subscribe to a request using S::C::R::subscribe, you currently get notified of requests that executed _before_ you placed the subscription. This is due to the asynchronous nature of notifications (and is probably also quantum). It would be great if the notification mechanism could store a timestamp for when a subscriber subscribed and then only send notifications if the requests occurred after that. If backwards compatibility is needed, the subscribe function could take an optional 'onlyFuture' parameter.
I'll look at this - probably keep a queue of pending subscriptions and add when there's nothing in the notification queue.
Max - afraid I won't get to this in time for 7.3
Is this still needed Max?
Moving to future till more feedback is received. Please re target when feedback is received.
Not too sure if this is the sort of feedabck you meant James. Here's a personal scenario that will continue to happen until this bug is dealt with. I have anm alrm set up so that at 7.00pm every day my kitchen SB3 fires up into BBC Radio 4 so I don't miss any episodes from my favourite radio drama. It's 15 minutes long and when it's finished we may turn off the player, but most times we choose some music to lilsten to when it's finshed. At some later point this music then unexpectedly stops dead as the alarm has timed out. If this bug is addressed then replacing the alarm playlist with a new one (as my family does) will cease the alarm function so the new playlist will continue to play (assuming it is implemented). It is quite likely that this problem affects most people who set alarms for any other reason than to get up in the morning to go to work.