[SERVER-34092] Add test for staleDbVersion when opening a change stream against a database that has been dropped and recreated Created: 23/Mar/18 Updated: 26/Apr/18 Resolved: 26/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Ian Boros |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Query 2018-04-23, Query 2018-05-07 |
| Participants: |
| Description |
|
It may be difficult to test, but there's a chance when a change stream is opened against a non-existent database that the AutoGetOrCreateDB helper throws a StaleDB exception. |
| Comments |
| Comment by Ian Boros [ 26/Apr/18 ] |
|
Closing as "Won't Fix" because of above comment. |
| Comment by Ian Boros [ 23/Apr/18 ] |
|
I don't think it's possible for this to happen for now, since the aggregate command doesn't send dbVersion: This means that any check for the command's dbVersion will be skipped in DatabaseShardingState: |