You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
delay(0.2) // This effectively blocks the emit as is expected for async streams. Due to the build in buffer policy of AysyncThrowing stream by default nothing is lost
47
50
receivedValueCount +=1
48
51
}
49
-
XCTAssertEqual(receivedValueCount, sendValueCount,"Should have received all values")
52
+
XCTAssertEqual(result,[
53
+
"0",
54
+
"1",
55
+
"2",
56
+
"3",
57
+
"4",
58
+
"5",
59
+
"6",
60
+
"7",
61
+
"8",
62
+
"9"
63
+
],"""
64
+
Should have received all values. You might notice that the middle, the emittedCount skips a beat.
65
+
This is normal als the delay here block the same caller queue until it is ready to receive another value.
66
+
When it is ready the AsyncThrowingStream emits a value from its, by default infinate, buffer. Hence effectively
67
+
allowing for all values to be passed into swift. This might not be abovious from just testing the emit count as that one skips a beat.
68
+
But in this case is the expected behaviour if you align with how streams behave in swift structured concurrency world.
69
+
""")
50
70
}catch{
51
71
XCTFail("Sequence should complete without an error")
// This will emit a value and return on the same queue which is the expected behaviour of async streams
86
+
// Old implementation returned on cooporative queue making the consumption of the sample not block the emit. This is not expected for async streams.
87
+
varresult:[String]=[]
88
+
fortryawaitvaluein sequence {
89
+
// Note the AsyncSequence buffers at most a single item
90
+
result.append("\(value)")
91
+
delay(0.2) // This effectively blocks the emit as is expected for async streams. Due to the build in buffer policy of AysyncThrowing stream by default nothing is lost
92
+
}
93
+
94
+
XCTAssertTrue(result.count <10,"""
95
+
This test shows that you have the option to force drops of items if consumption is too slow.
96
+
The values dropped are a bit random so a test with exact values is not possible. But it should be less then
97
+
10 values or the buffer is still active.
98
+
""")
99
+
}catch{
100
+
XCTFail("Sequence should complete without an error")
0 commit comments