Troubleshooting Service Broker: initiator database stuck CONVERSING/NOTIFIED

Question

We are developing an application that will use service broker to transfer messages from one database to another. SourceDB is used by an existing application from which we are siphoning off some data. TargetDB is used only by this application and processes/distributes the data we need. We are only using one type of contract and both DBs are on the same server.

We have set up identical message types and contracts on both, and respective initiator and target queue/service. On both databases:

• ENABLE_BROKER is set
• TRUSTWORTHY is set
• Have a unique service_broker_guid
• Have sa as db owner, with all SSB authorization statements are dbo or OWNER, as appropriate.

However, when we send a message from SourceDB:

BEGIN DIALOG CONVERSATION @dialogHandle
    FROM SERVICE [//Service/Initiator]
    TO SERVICE N'//Service/Target'
    ON CONTRACT [//Contract/Notification]
    WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @dialogHandle
    MESSAGE TYPE [//Message/Notification] (@RequestMsg);

...messages do not find their way there. Further investigation reveals the following:

• The initiator queue is empty
• The target queue is empty (NB: not an issue of needing to RECEIVE)
• The transmission queue is empty
• No errors are recorded, either in the SQL Server logs or in our CATCH error handling in the stored procedure that creates the message
• The initiator queue's entry in SourceDB's sys.dm_broker_queue_monitors is set to NOTIFIED if activation is enabled
• SourceDB's sys.conversation_endpoints has a new entry in CONVERSING state
• The target queue's entry in TargetDB's sys.dm_broker_queue_monitors remains INACTIVE if activation is enabled
• TargetDB's sys.conversation_endpoints has a new entry in CONVERSING state with the same conversation_id and different conversation_handle from SourceDB's entry

Although the test database is SQL 2005 (application must support 2005), I ran the ssbdiagnose utility from my development machine's 2008 installation to dianose the issue:

ssbdiagnose -S testserver -d SourceDB CONFIGURATION FROM SERVICE //Service/Initiator TO SERVICE //Service/Target ON CONTRACT //Contract/Notification

That produced the following:

D  29912 dbtestsvr  SourceDB  Service //Service/Target was not found
D  29975 dbtestsvr  SourceDB  User dbo does not have SEND permission on service //Service/Target

This is confusing, since dbo should not be denied any permission, and //Service/Target certainly does exist, albeit in a different database. But my coworker ran a Profiler trace that showed a command being executed looking for //Service/Target on SourceDB. Service broker seems to be getting confused somehow. Adding an explicit route, in addition to being theoretically unnecessary, does not change the situation.

I ran a nearly-identical set of tutorial commands on our test server and everything worked fine, so it is likely something db-specific.

Our setup was working two days ago, so we're probably looking for some setting that might have gotten changed, but with no luck.