Cratis.Cli.Integration.Chronicle.for_Users.when_adding_and_removing_user fails intermittently in CI. The same commit, re-run with no changes, passes.
What happens
chronicle users add succeeds — should_return_success_for_add and should_contain_added_message both pass — but the user is not in the chronicle users list output that follows, so should_show_user_in_list fails. The context then leaves RemoveResult null, and the two facts that read it fail with NullReferenceException:
Failed should_show_user_in_list Expected: True Actual: False
Failed should_return_success_for_remove System.NullReferenceException
Failed should_contain_removed_message System.NullReferenceException
Failed! - Failed: 3, Passed: 158, Total: 161
Evidence that it is a race and not a regression
Observed on #53, whose diff touches only the Screenplay command and the Cratis.Arc.Screenplay package version (whose dependency set is byte-identical between the two versions, so it cannot reach the Chronicle client):
- Run 30453708890 failed; re-running the same commit with no changes passed.
- The same specs pass 8/8 locally against a real Chronicle container.
Build dispatched on main (run 30453993074) is green.
Two separate things worth fixing
-
The read-back is not tolerant of the write being visible yet. users add returning success does not mean the user is already in users list. The spec reads the list once, immediately.
-
One race reports as three failures, two of them meaningless. RemoveResult is null! and dereferenced by two facts whenever the lookup misses, so a single missed read produces two NullReferenceExceptions that say nothing about what went wrong. Whatever is decided about the race, the dependent facts should not fail this way — a reader of the log cannot tell the cause from the symptom.
Cratis.Cli.Integration.Chronicle.for_Users.when_adding_and_removing_userfails intermittently in CI. The same commit, re-run with no changes, passes.What happens
chronicle users addsucceeds —should_return_success_for_addandshould_contain_added_messageboth pass — but the user is not in thechronicle users listoutput that follows, soshould_show_user_in_listfails. The context then leavesRemoveResultnull, and the two facts that read it fail withNullReferenceException:Evidence that it is a race and not a regression
Observed on #53, whose diff touches only the Screenplay command and the
Cratis.Arc.Screenplaypackage version (whose dependency set is byte-identical between the two versions, so it cannot reach the Chronicle client):Builddispatched onmain(run 30453993074) is green.Two separate things worth fixing
The read-back is not tolerant of the write being visible yet.
users addreturning success does not mean the user is already inusers list. The spec reads the list once, immediately.One race reports as three failures, two of them meaningless.
RemoveResultisnull!and dereferenced by two facts whenever the lookup misses, so a single missed read produces twoNullReferenceExceptions that say nothing about what went wrong. Whatever is decided about the race, the dependent facts should not fail this way — a reader of the log cannot tell the cause from the symptom.