Microsoft/coyote

A tool that helps ensure that your C# code is free of pesky concurrency bugs.

jtourvieille

@jtourvieille

Hello

I like your product, congrat!

I have a question: which tool did you use to build the animated state machine demo? https://microsoft.github.io/coyote/learn/programming-models/actors/state-machine-demo

Chris Lovett

@lovettchris

Hey, glad to hear you like it. The animations are easy to create, first you use our "coyote" tool to run a test with "--graph-bug" and "--xml-trace". The xml-trace file is used to play back the animation. The --graph-bug option produces a DGML diagram which you can load into Visual Studio 2019 (assuming you've enabled the DGML Editor optional component in the VS installer). Then you will need the DGMLPowerTools extension for VS 2019, this adds a "Save as SVG" option on the Share toolbar. But first you will need to change the "Link" layout using the Layout menu on the toolbar to "show all cross group links". Then save the file. It's prettier if you also enable edge bundling layout option. Then to run this in a web page you need the 3 javascript modules progress_bar.js, animate_trace.js and trace_model.js, and a <div> element that ties it all together like this: <div class="animated_svg" trace="/coyote/assets/data/Raft.xml" svg="/coyote/assets/images/Raft.svg" ></div>. The progress bar is also a bunch of UI controls that the progress_bar.js expects to find, it is the div labelled <div class="player-controls">...

Chris Lovett

@lovettchris

See updated answer https://github.com/microsoft/coyote/wiki/SVG-Animations

Vladimir Ivanov

@kripergvg

Hello. Thank you for this exciting project. I am curious did I get it right that if I use task primitives then a minimal primitive of testing is lambda?

For example, Coyote doesn't split my lambda and doesn't test the situation when t1 set x to 1 and t2 set x = 2 but y is still 0

Vladimir Ivanov

@kripergvg

This asserts doesn't detect the situation when x was set and y wasn't but it could happen in real-world scenario

Akash Lal

@akashlal

@kripergvg By default, Coyote will explore interleavings only at Task boundaries (spawn, await, etc.) so its not going to find the assert violation in your example. There are two options. First, in a real scenario, you would ideally have some protection (synchronization) against data races because your accesses to x and y are racy. Use synchronization like Coyote's asynchronous locks or semaphores. Coyote tester will then explore more fine-grained interleavings (at the level of the sychronization operations). The option is more low-level, where you can insert context switch points yourself. For instance, try inserting Task.ExploreContextSwitch between x=1 and y=1 and see what happens.

Vladimir Ivanov

@kripergvg

@akashlal Cool. Thank you for your answer.

Immad

@imnaseer

@kripergvg Like Akash said, Task.ExploreContextSwtich is the way to go if you want Coyote to explore data races around shared variables. In practice, a lot of interesting concurrency issues happen when reading/writing to external resources, say, database access and those accesses often end up spawning new Tasks so checking the interleavings at Task boundaries is fairly effective. Here is a way-too-detailed write-up talking through the natural interleavings of a small .NET code snippet and the subset which Coyote explores: https://github.com/imnaseer/coyote-explainer/blob/master/TaskBasedProgrammingModel.md

wanton7

@wanton7

Two questions

Why is there no timeout support for ReceiveEventAsync?
If I have storage that I want to support multiple messages coming in and I have actor like UserStoreActor. Then that actor delegates messages to other actors that it creates that are only used to receive and handle single message (one for every database request). What is the proper way to create those kind of actors? I mean do I call Halt() at end of its OnEntry method or what?

2 replies

wanton7

@wanton7

@akashlal it did answer my question and question wasn't properly formed it was about how do you create actor for single task, but issue I created to Coyote repo and answer you added there also answered that with an example. I'm evaluation Coyote for our app company I work for is building. What we have is just normal app with with React UI and API similar to REST. It's going to be multi-tenant app where tenants can register them self. I'm just trying to get my head around how Coyote works and how could we integrate to it to our app.

I'm still having little bit of trouble understanding how would we write tests all those events we will be sending from our API controllers to actor runtime using Coyote tests. Those event classes might be coming from JSON deserialization. Example we might have CommentCreateEvent that would contain Text property that should not be null, empty or over certain length. Should we use Coyote randoms to init properties like that so they will randomly have any of null, empty, ok (a valid value) or over max length value?

We would also like to write permission and authorization checking system using actor model. Example if I send GetChannelEvent and it would contain current workspace id, channel id to get and current user Id, how could I have shared authorization code to check If sending GetChannelEvent for that specific channel id is valid for current user? I mean is the a way to somehow forward it to permissions checking actors first? In our current proof of concept app we use MediatR and we do permissions checking in it's pipeline.

Akash Lal

@akashlal

@wanton7 Yes, you can use RandomBoolean or RandomInteger to construct a space of possible input values to drive your test.

I don't follow you authorization example. Decide first on breaking up the logic of your application into actors (e.g., one actor designated to do permissions-checking), then write the tests as if you are simulating a real workload through the system. In general, a coyote test can exercise multiple actors.

wanton7

@wanton7

@akashlal my explanations are quite bad :) What I wanted to ask that is there a way to route GetChannelEvent through some permission checking actor automatically. If not what would be best way to model that? Example should I send event to channel permissions checker actor and that would then forward event to ChannelManager if check passes or if check fails it would directly send failure event to caller?

Akash Lal

@akashlal

@wanton7 What you are saying sounds good. There is no default support in Coyote for doing this; you'll have to program the logic yourself. It is usual for applications to have a network of actors.

wanton7

@wanton7

@akashlal Thanks good to know that I have do it myself so I can focus on designing how to best do it for our use case.

Chris Lovett

@lovettchris

I could imagine using Monitors for "Checking" that something is authorized. Monitors are good for asserting some global condition is true across all your actors. So the entry point could send current user id to a Monitor, and later code could send authorization messages to the same Monitor which then asserts the user is authorized for that action to be done. The Monitor then acts as an authorization checker...

Noel

@nanderto

Are there any samples for how Coyote can be used in a ASP.Net (or WebApi) application. I cant find any way or receiving a message back from an actor without being an actor. And If my receiving end has to be a Actor the how do I get a reference to the Actor so that I can access the data in it? the only CreateActor() method returns an ActorID.

wanton7

@wanton7

@nanderto check this microsoft/coyote#22

Chris Lovett

@lovettchris

I captured that into in the wiki also: https://github.com/microsoft/coyote/wiki/Request-Response-Actors

wanton7

@wanton7

Is it still true what docs say that you can't mix Task and Actor based Coyote programming models in same process?

Noel

@nanderto

@lovettchris @wanton7 Thanks for the help. I could not get the last line of your code to compile "Return new ActionResult<string>(response);", and I have not used MVC for a while (all Razor Pages) but I did get it to compile and run eventually. Thanks for the help.

Chris Lovett

@lovettchris

@wanton7, The most important information is on actors overview where it says: Async handlers are allowed so that you can call external async systems in your production code, but this has some restrictions. You are not allowed to directly create parallel tasks inside an actor (e.g. by using Task.Run) as that can introduce race conditions (if you need to parallelize a workload, you can simply create more actors). Also, during testing, you should not use Task.Delay or Task.Yield in your event handlers. It is ok to have truly async behavior in production, but at test time the coyote test tool wants to know about, so that it can control, all async behavior of your actor. If it detects some uncontrolled async behavior an error will be reported.

wanton7

@wanton7

@lovettchris what I was thinking that we would write most of our app with Task based concurrency (using Coyote Tasks) and then write our caching system in same process using actors and Coyote Tasks would call into caching actor system in same process. Is this possible?

Note that you cannot use the above two programming models at the same time in the same process.

at https://microsoft.github.io/coyote/learn/overview/what-is-coyote
Makes me think it's not possible to do.

Akash Lal

@akashlal

@wanton7 You can certainly build your application like you suggested. It is fine to use both Coyote Tasks and Coyote Actors in the same process. The process will run just fine and both Tasks and Actors will inter-operate seamlessly. What is not supported is a Coyote test that exercises both. The coyote test tool currently does not expected to see both programming models in the same test case. One option for you is perhaps that you turn off the (Actor-based) caching when testing the Task-based part of your code, and then test the caching layer separately.

wanton7

@wanton7

@akashlal thanks for the info. My idea was to use them as separate systems anyway. Using actor's turn based concurrency makes local & distributed cache invalidation so much simpler.

@akashlal anyway our team has to think should we go in for message based actor model or do we still stick mostly with Task based one.

Lane Kelly

@lanekelly

Does Coyote support installation as a .NET Core CLI tool? https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools

I think it would be an improvement in user-friendliness over the current approach listed here: https://microsoft.github.io/coyote/learn/get-started/using-coyote

Lane Kelly

@lanekelly

Got it working as a CLI tool quite easily, although I had to restrict the Coyote project targets to netcoreapp2.2 only.

1 reply

wanton7

@wanton7

Our app is currently at this early stage and app that has web api endpoints that contain business logic and call into database and we send some SignalR messages to UI. We actually have had some projects in past where message based actor system would have helped greatly. But I'm not sure what kind of benefits would it bring to our current app. Ones I can think of are easier caching because of turn based Actors and it will be easier to split app into microservices. Plus testing bonuses Coyote will bring. Are there other benefits I'm missing?

Akash Lal

@akashlal

@wanton7 Actors are useful when you can divide up your state into the Actors that will own them. Start with one layer of your system and see the testing benefits that Coyote brings to the table. That will be a good start to evaluate further benefits.

Chris Blackmoor

@Chobbly_gitlab

Hi there. I'm looking at evaluating Coyote for an actor-model project that I'm hoping will kick off in the next few months. I know Orleans is already established but having a read through of the documentation there's a lot in Coyote which would be of benefit. One of the requirements though is that the project will need to run on a supported version of .NET Core, so 3.1 or later. Does anyone know if there any plans to update Coyote to .NET Core 3.1 in the near future?

Akash Lal

@akashlal

@Chobbly_gitlab Yes, 3.1 is coming. To quote @pdeligia

Regarding netcoreapp2.2, we plan to change to a netcoreapp3.1 target (which is LTS, https://dotnet.microsoft.com/download/visual-studio-sdks, 2.2 is now end-of-life)

Where communities thrive

People

Repo info

Activity