jordansjones / draft Goto Github PK

In many of the draft unit tests we create a new testing context like this:

using (var http = new HttpTest()) {
    http.RespondWithJson(Fixtures.Directory.DefaultResponse);

Intermittently, the call to RespondWithJson will throw a NullReferenceException.

in flurl, the source code for this call is (currently) this:

public HttpTest RespondWithJson(object body, int status = 200, object headers = null, object cookies = null, bool replaceUnderscoreWithHyphen = true) {
	var content = new CapturedJsonContent(Settings.JsonSerializer.Serialize(body));
	return RespondWith(content, status, headers, cookies, replaceUnderscoreWithHyphen);
}

https://github.com/tmenier/Flurl/blob/80cf699ef8b153c0c0fd2324a426f54f39197fd0/src/Flurl.Http/Testing/HttpTest.cs#L92-L95

The only case where we can possibly throw a null reference exception is if either Settings is null or Settings.JsonSerializer is null. In this case it is Settings.JsonSerializer, but Settings actually has a public setter so if you want to deliberately cause a similar error you could call http.Settings = null, but we're not doing that in draft tests.

When Settings.JsonSerializer is called, it first attempts to find a local value for JsonSerializer, and if it fails to find a local setting it then looks for a local default, and ultimately falls through to the globally configured static defaults accessed at FlurlHttp.GlobalSettings. In all of the test cases, we fall all the way through to the static global settings searching for an instance of JsonSerializer that can be used to configure the JsonResponse for the test.

Accessing settings in FlurlHttp.GlobalSettings is not thread-safe to be used across tests because it has the following publicly exposed method:

public override void ResetDefaults() {
	base.ResetDefaults();
	Timeout = TimeSpan.FromSeconds(100); // same as HttpClient
	JsonSerializer = new NewtonsoftJsonSerializer(null);
	UrlEncodedSerializer = new DefaultUrlEncodedSerializer();
	FlurlClientFactory = new PerHostFlurlClientFactory();
	HttpClientFactory = new DefaultHttpClientFactory();
}

https://github.com/tmenier/Flurl/blob/80cf699ef8b153c0c0fd2324a426f54f39197fd0/src/Flurl.Http/Configuration/FlurlHttpSettings.cs#L212-L219

Here, base.ResetDefaults() empties the global settings before they are reset to the hard-coded defaults

public virtual void ResetDefaults() {
	_vals.Clear();
}

https://github.com/tmenier/Flurl/blob/80cf699ef8b153c0c0fd2324a426f54f39197fd0/src/Flurl.Http/Configuration/FlurlHttpSettings.cs#L131-L133

So there exists a period of time where any of the global settings could be null, including JsonSerializer, if ResetDefaults() is called.

We have a set of tests which call FlurlHttp.GlobalSettings.ResetDefaults() explicitly (see

When all of the unit tests are run in parallel, we have a chance for the global defaults to be reset at the same time that we are trying to configure a json response, possibly resulting in the observed NullReferenceException.

When this offending line is removed (below) I no longer can reproduce any intermittent test failures.

Requests

• Leader Statistics Moving to 0.3.0 (#3)
• Self Statistics Moving to 0.3.0 (#3)
• Store Statistics Moving to 0.3.0 (#3)

Unit Tests

• Cluster Moving to 0.3.0 (#3)
• Statistics Moving to 0.3.0 (#3)

Enhancements

• Draft.Etcd.ClientFor vararg support. (f3ba582)
• Asynchronous Draft.Etcd.ClientFor which validates the passed Uri(s) (f3ba582)

Is this library compatible with etcd v3 protocol and new functions?

I'm seeing this error in one of my enterprise applications.

System.Runtime.Serialization.SerializationException: Type 'Draft.Exceptions.InvalidActiveSizeException' in Assembly 'Dra
ft, Version=0.1.1.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable.
   at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize(Object obj, ISurrogateSelector surrog
ateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter
objectWriter, SerializationBinder binder)
   at System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Object obj, ISurrogateSelector surrogateS
elector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter obje
ctWriter, SerializationBinder binder)
   at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWr
iter serWriter, Boolean fCheck)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph,
Header[] headers, Boolean fCheck)

Should that exception be marked serializable?

Requests

• Leader Statistics
• Self Statistics
• Store Statistics

Unit Tests

• Cluster (055960b82e32ecba4358407c868eb3edf46b0741)
• Statistics

Hi,
I am getting below error "The selected verification strategy requires all passed endpoints to respond. The following are not responding:https:///, https:///, https:///"}"
with below code
_endpointPool = await EndpointPool.Build()
.WithRoutingStrategy(EndpointRoutingStrategy.RoundRobin)
.WithVerificationStrategy(EndpointVerificationStrategy.All)
.VerifyAndBuild(new Uri("https://"),
new Uri("https://"),
new Uri("https://"));

The endpoints responds well with curl commands. Are there any settings recommended with https?

Thanks,
Vijay

First - thanks for the library, seems to work well and looks cleaner than some of the other etcd clients. The work is appreciated.

Second - any chance of adding support for a Uri[] array for the ClientFor factory? I have 5 instances, ideally it would iterate through and find the first one that's up to use.

I will probably use my own wrapper to do this for now, but if you get bored ;)

I went a bit further in my perl client and actually assert that the server is up and working (and optionally the master) before every request. Bit slower but I'm more worried about resiliency at this point.