Azure SQL DB Basic Edition Preview: "Session Request Limit Reached" Stuck and Doesn't Clear - SQL DB Bug?

Question

Edit: I have updated the below to reflect that it took four hours for the database to unblock. This looks like a bug to me. SQL Server seemed to believe there were 30 running sessions with open requests nearly four hours after the client
side connections were terminated (and thus in the process blocking SQL Server from accepting new connections).
Problem
I am running a preview "Basic" edition SQL DB and have hit a problem with Azure SQL DB blocking database access for an extended time period.
I was running a test, which was running normally for several hours (loading small batches of data), then suddenly lots of connection timeouts (error type 1 below).  My workload was constant over the whole test - but if the server was suddenly under
pressure, I accept this might happen - no problem with me so far. 
Upon retrying, the errors then changed to request limit exceeded (error type 2 below).
I am surprised I hit the limit in the first place, since the test code closes the SQL Connection on a timeout error and reopens.  (In C#, the code is wrapped in a using{} to ensure prompt connection closure).  Still, perhaps the amount of concurrent
work on the server did momentarily hit this limit.  Perhaps fair enough on this point too.
BUT:  Surprisingly, nearly four hours later, I was still unable to connect to the database - it was refusing new connections.  Either from my worker role or from the Azure Management Website.  The Management Window, upon trying to connect,
failed with exactly the same text as error type 2 below.
Further, sys.resource_stats (from the master db, which is still accessible) is reporting that there were 30 active sessions, 30 active workers (see extract below) for four afters after the test ended.  Even though during this time period the Azure Cloud
Service that was generating the SQL requests was stopped too (so the client side of any open requests were long since dead).  Also,
the CPU, Log Write and Phys Data Read columns in sys.resource_stats are all showing 0 for the four hours after the test ended.  This to me suggests a fault condition that isn't clearing server-side.
Why was the database unavailable for four hours?  Why did Azure believe that there were 30 open requests? (each request was an insert of 1000 rows, each of 400 bytes, i.e. pretty small so no way should they take this long to process).
PS.  To be clear, none of the above is a complaint.  I completely accept that the service in in preview, different SLA, etc.  I am writing to a) check that I haven't missed anything and b) if this is a bug, to report it.
Appendix
Error Type 1
System.Data.SqlClient.SqlException:  Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
Error Type 2
SqlException: Resource ID : 1. The request limit for the database is 30 and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.
Metrics
The following is an extract from sys.resource_stats for the affected time period.  SQL Server seems to wrongly believe/report that there are 30 pending requests between 6:20 and 10:45.  It thus blocks any further requests during this time.  There
were NO client connections during this time, either new or previously opened.
start time
end time
sku
session count
worker count
avg cpu
avg phys data read
avg log write
07 Jun 11:15
07 Jun 11:20
Basic
  0
0
0
0
0
07 Jun 10:50
07 Jun 10:55
Basic
  0
0
0.5
0
0
07 Jun 10:40
07 Jun 10:45
Basic
  30
30
0.01
0
0
07 Jun 09:35
07 Jun 09:40
Basic
  30
30
0.02
0
0
07 Jun 09:20
07 Jun 09:25
Basic
  30
30
0
0
0
07 Jun 09:10
07 Jun 09:15
Basic
  30
30
0.01
0
0
07 Jun 08:40
07 Jun 08:45
Basic
  30
30
0
0
0
07 Jun 08:20
07 Jun 08:25
Basic
  30
30
0.01
0
0
07 Jun 08:10
07 Jun 08:15
Basic
  30
30
0.01
0
0
07 Jun 07:55
07 Jun 08:00
Basic
  30
30
0
0
0
07 Jun 07:25
07 Jun 07:30
Basic
  30
30
0.01
0
0
07 Jun 07:15
07 Jun 07:20
Basic
  30
30
0
0
0
07 Jun 07:05
07 Jun 07:10
Basic
  30
30
0.01
0
0
07 Jun 06:55
07 Jun 07:00
Basic
  30
30
0
0
0
07 Jun 06:45
07 Jun 06:50
Basic
  30
30
0.15
0
0
07 Jun 06:20
07 Jun 06:25
Basic
  30
30
0.01
0
0
07 Jun 06:15
07 Jun 06:20
Basic
  30
30
0.22
0
0
07 Jun 06:10
07 Jun 06:15
Basic
  26
26
0.13
0
0
07 Jun 06:05
07 Jun 06:10
Basic
  20
20
0.14
0
0
07 Jun 06:00
07 Jun 06:05
Basic
  13
13
0.12
0
0
07 Jun 05:55
07 Jun 06:00
Basic
  7
7
0.12
0
0
07 Jun 05:50
07 Jun 05:55
Basic
  1
1
54.04
0
93.47
07 Jun 05:45
07 Jun 05:50
Basic
  1
0
1.4
0
2.06
07 Jun 05:40
07 Jun 05:45
Basic
  1
1
55.17
0
88.35
07 Jun 05:35
07 Jun 05:40
Basic
  1
0
52.05
0
90.01
07 Jun 05:30
07 Jun 05:35
Basic
  1
1
54.95
0
90.1
07 Jun 05:25
07 Jun 05:30
Basic
  1
1
56.38
0
89.82
07 Jun 05:20
07 Jun 05:25
Basic
  1
0
52.15
0
90.19
07 Jun 05:15
07 Jun 05:20
Basic
  1
0
52.76
0
87.86

Answer 1

Hi Chris,
Thanks for testing the new Basic edition and for reporting this issue. Without some more investigation it is hard to tell what exactly has happened here.
To be able to take a closer look I would need some more information from you. Could you please reach out to me via email (firstname DOT lastname AT microsoft DOT com)? I will then let you know what additional information we and will kick-off
the investigation.
Thanks,
Jan