Flaky tests: discard stale events#1066
Conversation
|
A new one 😭 |
|
I've pushed a fix for GraphQL ... it's a bit unfortunate that we don't have a reliable way to know when a server is ready to answer to client requests. |
|
Unfortunately the failed logs do not show anything and I can't repro the error anywhere... |
@samoht: I assume from this that |
About that, from what I know (and what I did on
Even if it returns before, |
|
I pushed a commit that adds |
|
The verbose output seems to give an interesting trace, where a |
b72ef88 to
bdf0af3
Compare
|
New similar issue: |
7a794e6 to
a4a47ba
Compare
There are two different ways to produce events (which are then consumed by watchers): - every update to the reference store will call notify, which will notify watcher connected to the same repository in that process - there is a background thread, using irmin-watcher (with either polling mode, inotify or fsevents), which check for filesystem changes, and call notify whenever a reference change. It is necessary that the events are delivered in (commit) order, as the API is exposing diffs and it would be confusing if the events go back in time. There is a small race right now between these two mechanism: the background thread could read a new reference value, be interrupted, and then call notify. During that interuption, the store can change and events be delivered. If that's the case, we want to discard the current event and try again.
…lient connections
|
f4fdc0f should fix the race ; the watches were not initialised properly and the background event loop were triggering an |
|
And now, a new connection race: |
|
Travis is failing due a transient GH error (while downloading archives). Merging. |
Discard stale events
There are two different ways to produce events (which are then consumed by watchers):
It is necessary that the events are delivered in (commit) order, as the API is exposing diffs and it would be confusing if the events go back in time.
There is a small race right now between these two mechanism: the background thread could read a new reference value, be interrupted, and then call notify. During that interruption, the store can change and events be delivered. If that's the case, we want to discard the current event and try again.